- 11 May, 2012 40 commits
-
-
David Woodhouse authored
[ This combines upstream commit e675f0cc and follow-on bug fix commit 9a5d2bd9 ] For every transmitted packet, ppp_start_xmit() will stop the netdev queue and then, if appropriate, restart it. This causes the TX softirq to run, entirely gratuitously. This is "only" a waste of CPU time in the normal case, but it's actively harmful when the PPP device is a TEQL slave — the wakeup will cause the offending device to receive the next TX packet from the TEQL queue, when it *should* have gone to the next slave in the list. We end up seeing large bursts of packets on just *one* slave device, rather than using the full available bandwidth over all slaves. This patch fixes the problem by *not* unconditionally stopping the queue in ppp_start_xmit(). It adds a return value from ppp_xmit_process() which indicates whether the queue should be stopped or not. It *doesn't* remove the call to netif_wake_queue() from ppp_xmit_process(), because other code paths (especially from ppp_output_wakeup()) need it there and it's messy to push it out to the other callers to do it based on the return value. So we leave it in place — it's a no-op in the case where the queue wasn't stopped, so it's harmless in the TX path. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
J. Bruce Fields authored
commit 9dc4e6c4 upstream. Allow a v3 unchecked open of a non-regular file succeed as if it were a lookup; typically a client in such a case will want to fall back on a local open, so succeeding and giving it the filehandle is more useful than failing with nfserr_exist, which makes it appear that nothing at all exists by that name. Similarly for v4, on an open-create, return the same errors we would on an attempt to open a non-regular file, instead of returning nfserr_exist. This fixes a problem found doing a v4 open of a symlink with O_RDONLY|O_CREAT, which resulted in the current client returning EEXIST. Thanks also to Trond for analysis. Reported-by:
Orion Poplawski <orion@cora.nwra.com> Tested-by:
Orion Poplawski <orion@cora.nwra.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> [bwh: Backported to 3.2: use &resfh, not resfh] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Eric Dumazet authored
[ Upstream commit 2def16ae ] Commit f04565dd (dev: use name hash for dev_seq_ops) added a second regression, as some devices are missing from /proc/net/dev if many devices are defined. When seq_file buffer is filled, the last ->next/show() method is canceled (pos value is reverted to value prior ->next() call) Problem is after above commit, we dont restart the lookup at right position in ->start() method. Fix this by removing the internal 'pos' pointer added in commit, since we need to use the 'loff_t *pos' provided by seq_file layer. This also reverts commit 5cac98dd (net: Fix corruption in /proc/*/net/dev_mcast), since its not needed anymore. Reported-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Mihai Maruseac <mmaruseac@ixiacom.com> Tested-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Felipe Balbi authored
commit cd423dd3 upstream. due to a HW limitation we have a bounce buffer for ep0 out transfers which are not aligned with MaxPacketSize. On such case we were not increment r->actual as we should. This patch fixes that mistake. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit e847469b upstream. comparing be32 values for < is not doing the right thing... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit 72094e43 upstream. le16, not le32... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit 28748b32 upstream. le16, not le32... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit e1bf4cc6 upstream. it's le16, not le32 or le64... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit 3a251f04 upstream. It's le16, not le32... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit 6ed3cf2c upstream. ->root_flags is __le64 and all accesses to it go through the helpers that do proper conversions. Except for btrfs_root_readonly(), which checks bit 0 as in host-endian... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit efe39651 upstream. Restore the original logics ("fail on mountpoints, negatives and in case of fh_compose() failures"). Since commit 8177e (nfsd: clean up readdirplus encoding) that got broken - rv = fh_compose(fhp, exp, dchild, &cd->fh); if (rv) goto out; if (!dchild->d_inode) goto out; rv = 0; out: is equivalent to rv = fh_compose(fhp, exp, dchild, &cd->fh); out: and the second check has no effect whatsoever... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit 02f5fde5 upstream. ->ts_id_status gets nfs errno, i.e. it's already big-endian; no need to apply htonl() to it. Broken by commit 174568 (NFSD: Added TEST_STATEID operation) last year... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit 04da6e9d upstream. nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit 96f6f985 upstream. ..._want_write() returns -EROFS on failure, _not_ an NFS error value. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Gertjan van Wingerde authored
commit bc93eda7 upstream. According to the latest USB ID database these are all RT2770 / RT2870 / RT307x devices. Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context for previously cherry-picked commit d42a179b 'rt2x00: Add support for D-Link DWA-127 to rt2800usb'] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Alan Cox authored
commit 3ac44670 upstream. Just another USB identifier. Signed-off-by:
Alan Cox <alan@linux.intel.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Kenth Eriksson authored
commit 5039a869 upstream. Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed device initialization to be children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization. Signed-off-by:
Kenth Eriksson <kenth.eriksson@transmode.com> Acked-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Laurent Pinchart authored
commit 178db7d3 upstream. Device are added as children of the bus master's parent device, but spi_unregister_master() looks for devices to unregister in the bus master's children. This results in the child devices not being unregistered. Fix this by registering devices as direct children of the bus master. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Jason Baron authored
commit 93dc6107 upstream. Commit 28d82dc1 ("epoll: limit paths") that I did to limit the number of possible wakeup paths in epoll is causing a few applications to longer work (dovecot for one). The original patch is really about limiting the amount of epoll nesting (since epoll fds can be attached to other fds). Thus, we probably can allow an unlimited number of paths of depth 1. My current patch limits it at 1000. And enforce the limits on paths that have a greater depth. This is captured in: https://bugzilla.redhat.com/show_bug.cgi?id=681578Signed-off-by:
Jason Baron <jbaron@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
AceLan Kao authored
commit 55ed7d4d upstream. Add another vendor specific ID for Atheros AR3012 device. This chip is wrapped by Lite-On Technology Corp. output of usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3005 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Gustavo Padovan <gustavo@padovan.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
AceLan Kao authored
commit 2d5de9e8 upstream. Touchpad LED will not turn on after S3, it will make the touchpad status doesn't consist with the LED. By adding one flag to let the LED device restore it's status. Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
AceLan Kao authored
commit 2a748853 upstream. Add "Vostro 3555", "Inspiron N311z", and "Inspiron M5110" into quirks, so that they could have touchpad LED function work. Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Alex Williamson authored
commit 32f6daad upstream. We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared. Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Al Viro authored
commit af1584f5 upstream. ->ee_len is __le16, so assigning cpu_to_le32() to it is going to do Bad Things(tm) on big-endian hosts... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Thomas Jarosch authored
commit f67fd55f upstream. Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-. These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts. Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug. Tested on the following boards: - Intel DH61CR: Affected - Intel DH67BL: Affected - Intel S1200KP server board: Affected - Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed. According to reports on the net, the Intel DH61WW board is also affected. Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation. Signed-off-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Tested-by:
Charlie Suffin <charlie.suffin@stratus.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Shubhrajyoti D authored
commit ad579699 upstream. pm_runtime_get_sync returns a signed integer. In case of errors it returns a negative value. This patch fixes the error check by making it signed instead of unsigned thus preventing register access if get_sync_fails. Also passes the error cause to the debug message. Cc: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Kishon Vijay Abraham I authored
commit 3006dc8c upstream. pm_runtime_enable is being called after omap2430_musb_init. Hence pm_runtime_get_sync in omap2430_musb_init does not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Andrzej Pietrasiewicz authored
commit 92b0abf8 upstream. usb: gadget: eliminate NULL pointer dereference (bugfix) This patch fixes a bug which causes NULL pointer dereference in ffs_ep0_ioctl. The bug happens when the FunctionFS is not bound (either has not been bound yet or has been bound and then unbound) and can be reproduced with running the following commands: $ insmod g_ffs.ko $ mount -t functionfs func /dev/usbgadget $ ./null where null.c is: #include <fcntl.h> #include <linux/usb/functionfs.h> int main(void) { int fd = open("/dev/usbgadget/ep0", O_RDWR); ioctl(fd, FUNCTIONFS_CLEAR_HALT); return 0; } Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Alan Stern authored
commit 320cd1e7 upstream. This patch (as1548) fixes a recently-introduced incompatibility between the UDC core and the dummy-hcd driver. Commit 8ae8090c (usb: gadget: udc-core: fix asymmetric calls in remove_driver) moved the usb_gadget_udc_stop() call in usb_gadget_remove_driver() below the usb_gadget_disconnect() call. As a result, usb_gadget_disconnect() gets called at a time when the gadget driver believes it has been unbound but dummy-hcd believes it has not. A nasty error ensues when dummy-hcd calls the gadget driver's disconnect method a second time. To fix the problem, this patch moves the gadget driver's unbind notification after the usb_gadget_disconnect() call. Now nothing happens between the two unbind notifications, so nothing goes wrong. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Felipe Balbi authored
commit 83a787a7 upstream. commit 6d258a4c (usb: gadget: udc-core: stop UDC on device-initiated disconnect) introduced another case of asymmetric calls when issuing a device-initiated disconnect. Fix it. Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Kishon Vijay Abraham I authored
commit 8ae8090c upstream. During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop. This is needed to avoid issues with PM where udc_stop disables the module completely (put IP in reset state, cut functional and interface clocks, and so on), which prevents us from accessing the IP's address space, thus creating the possibility of an abort exception when we try to access IP's address space after clocks are off. Signed-off-by:
Partha Basak <p-basak2@ti.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Felipe Balbi authored
commit 6d258a4c upstream. When we want to do device-initiated disconnect, let's make sure we stop the UDC in order to e.g. allow lower power states to be achieved by turning off unnecessary clocks and/or stoping PHYs. When reconnecting, call ->udc_start() again to make sure UDC is reinitialized. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Alan Stern authored
commit 8963c487 upstream. This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock: The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held. usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound. The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children. usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device(). The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered. This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter. [This should be marked for stable kernels that contain the commit fccf4e86 "USB: Free bandwidth when usb_disable_device is called." That commit was marked for stable kernels as old as 2.6.32.] Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Alan Stern authored
commit 2fbe2bf1 upstream. This patch (as1544) fixes a problem affecting some EHCI controllers. They can generate interrupts whenever the STS_FLR status bit is turned on, even though that bit is masked out in the Interrupt Enable register. Since the driver doesn't use STS_FLR anyway, the patch changes the interrupt routine to clear that bit whenever it is set, rather than leaving it alone. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Alan Stern authored
commit dc75ce9d upstream. This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended. Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended. In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <B29397@freescale.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Bjørn Mork authored
commit 749541d1 upstream. These devices have a number of non serial interfaces as well. Use the existing "Direct IP" blacklist to prevent binding to interfaces which are handled by other drivers. We also extend the "Direct IP" blacklist with with interfaces only seen in "QMI" mode, assuming that these devices use the same interface numbers for serial interfaces both in "Direct IP" and in "QMI" mode. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Julia Lawall authored
commit d3a7b83f upstream. tty_unlock is used on all other exits from the function. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Tomoya MORINAGA authored
commit af6d17cd upstream. This driver anticipates pch_uart_verify_port() is not called during installation. However, actually pch_uart_verify_port() is called during installation. As a result, memory access violation occurs like below. 0. initial value: use_dma=0 1. starup() - dma channel is not allocated because use_dma=0 2. pch_uart_verify_port() - Set use_dma=1 3. UART processing acts DMA mode because use_dma=1 - memory access violation occurs! This patch fixes the issue. Solution: Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated. Signed-off-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Yuri Matylitski authored
commit 2d5733fc upstream. Fixed too small hardcoded timeout values for usb_control_msg in driver for SiliconLabs cp210x-based usb-to-serial adapters. Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT. Signed-off-by:
Yuri Matylitski <ym@tekinsoft.com> Acked-by:
Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Shaohua Li authored
commit 99aa7846 upstream. flush request is issued in transaction commit code path, so looks using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. I saw btrfs and dm get it right, but ext4, xfs and md are using GFP. Signed-off-by:
Shaohua Li <shli@fusionio.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-