- 11 Nov, 2011 35 commits
-
-
Charles Chin authored
commit 6c5c04e5 upstream. The purpose of this patch is to remove a section of "bad" code that assigns the last DAC to ports E or F in order to support notebooks with docking in earlier days, around ALSA 1.0.19 - 21. This is not necessary now and actually breaks some configurations that use these ports as other devices. This have been tested on several different configurations to make sure that it is working for different combinations. Signed-off-by:
Charles Chin <Charles.Chin@idt.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jeff Skirvin authored
commit 983d3fdd upstream. Needed to jump to scic_lock unlock. Also spotted by coccicheck. Signed-off-by:
Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Williams authored
commit 54b5e3a4 upstream. Kill the local smp response buffer. Besides being unnecessary, it is too small (currently truncates responses to 60 bytes). The mid-layer will have already allocated a sufficiently sized buffer, just kmap and copy into it directly. Reported-by:
Derick Marks <derick.w.marks@intel.com> Tested-by:
Derick Marks <derick.w.marks@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jack Wang authored
commit bb041a0e upstream. Libsas forget to set the sas_address and device type of rphy lead to file under /sys/class/sas_x show wrong value, fix that. Signed-off-by:
Jack Wang <jack_wang@usish.com> Tested-by:
Crystal Yu <crystal_yu@usish.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Anton Blanchard authored
commit 5d7c20b7 upstream. During kdump testing I noticed timeouts when initialising each IPR adapter. While the driver has logic to detect an adapter in an indeterminate state, it wasn't triggering and each adapter went through a 5 minute timeout before finally going operational. Some analysis showed the needs_hard_reset flag wasn't getting set. We can check the reset_devices kernel parameter which is set by kdump and force a full reset. This fixes the problem. Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
adam radford authored
commit f575c5d3 upstream. The following patch for megaraid_sas will fix a potential bad pointer access in megasas_reset_timer(), when a MegaRAID 9265/9285 or 9360/9380 gets a timeout. megasas_build_io_fusion() sets SCp.ptr to be a struct megasas_cmd_fusion *, but then megasas_reset_timer() was casting SCp.ptr to be a struct megasas_cmd *, then trying to access cmd->instance, which is invalid. Just loading instance from scmd->device->host->hostdata in megasas_reset_timer() fixes the issue. Signed-off-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Josh Boyer authored
commit 3e309cdf upstream. Commit 15bed0f2 added a quirk for the e823 Ricoh card reader to lower the base frequency. However, the quirk first checks to see if the proprietary MMC controller is disabled, and returns if so. On some devices, such as the Lenovo X220, the MMC controller is already disabled by firmware it seems, but the frequency change is still needed so sdhci-pci can talk to the cards. Since the MMC controller is disabled, the frequency fixup was never being run on these machines. This moves the e823 check above the MMC controller check so that it always gets run. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=722509Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andrei Warkentin authored
commit 5238acbe upstream. f39b2dd9 ("mmc: core: Bus width testing needs to handle suspend/resume") added code to only compare read-only ext_csd fields in bus width testing code, yet it's comparing some fields that are never set. The affected fields are ext_csd.raw_erased_mem_count and ext_csd.raw_partition_support. Signed-off-by:
Andrei Warkentin <andrey.warkentin@gmail.com> Acked-by:
Philip Rakity <prakity@marvell.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ulf Hansson authored
commit 7f7e4129 upstream. During a rescan operation mmc_attach(sd|mmc|sdio) functions are called. The error handling in these function can trigger a detach of the bus, which also meant a power off. This is not notified by the rescan operation which then continues to the next attach function. If a power off has been done, the framework must never send any new commands to the host driver, without first doing a new power up. This will most likely trigger any host driver to hang. Moving power off out of detach and instead handle power off separately when it is actually needed, solves the issue. Signed-off-by:
Ulf Hansson <ulf.hansson@stericsson.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
commit 286e0c94 upstream. Commit 9b9fe724 accidentally used RADEON_GPIO_EN_* where RADEON_GPIO_MASK_* was intended. This caused improper initialization of I2C buses, mostly visible when setting i2c_algo_bit.bit_test=1. Using the right constants fixes the problem. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Jerome Glisse <j.glisse@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Deucher authored
commit d0d0a225 upstream. When force == false, we don't do load detection in the connector detect functions. Unforunately, we also return the previous connector state so we never get disconnect events for DVI-I, DVI-A, or VGA. Save whether we detected the monitor via load detection previously and use that to determine whether we return the previous state or not. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41561Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Deucher authored
commit 5f0a2612 upstream. DVI-D and HDMI-A are digital only, so there's no need to attempt analog load detect. Also, skip bail before the !force check, or we fail to get a disconnect events. The next patches in the series attempt to fix disconnect events for connectors with analog support (DVI-I, HDMI-B, DVI-A). Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41561Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jesse Barnes authored
commit 26005210 upstream. SPD frames are actually type 0x83, not just 0x3. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Takashi Iwai authored
commit f52c619a upstream. The commit 47356eb6 introduced a mechanism to record the backlight level only at disabling time, but it also introduced a regression. Since intel_lvds_enable() may be called without disabling (e.g. intel_lvds_commit() calls it unconditionally), the backlight gets back to the last recorded value. For example, this happens when you dim the backlight, close the lid and open the lid, then the backlight suddenly goes to the brightest. This patch fixes the bug by recording the backlight level always when changed via intel_panel_set_backlight(). And, intel_panel_{enable|disable}_backlight() call the internal function not to update the recorded level wrongly. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Keith Packard authored
commit 8c241fef upstream. Talking to the eDP DDC channel requires that the panel be powered up. Wrap both the EDID and modes fetch code with calls to turn the vdd power on and back off. Signed-off-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andiry Xu authored
commit 7e393a83 upstream. Setting the chain (CH) bit in the link TRB of isochronous transfer rings is required by AMD 0.96 xHCI host controller to successfully transverse multi-TRB TD that span through different memory segments. When a Missed Service Error event occurs, if the chain bit is not set in the link TRB and the host skips TDs which just across a link TRB, the host may falsely recognize the link TRB as a normal TRB. You can see this may cause big trouble - the host does not jump to the right address which is pointed by the link TRB, but continue fetching the memory which is after the link TRB address, which may not even belong to the host, and the result cannot be predicted. This causes some big problems. Without the former patch I sent: "xHCI: prevent infinite loop when processing MSE event", the system may hang. With that patch applied, system does not hang, but the host still access wrong memory address and isoc transfer will fail. With this patch, isochronous transfer works as expected. This patch should be applied to kernels as old as 2.6.36, which was when the first isochronous support was added for the xHCI host controller. Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kautuk Consul authored
commit 0e6c7f74 upstream. There are 2 situations wherein the xhci_ring* might not get freed: - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and we goto the fail: label in xhci_ring_alloc. In this case, the ring will not get kfreed. - When the num_segs argument to xhci_ring_alloc is passed as 0 and we try to free the rung after that. ( This doesn't really happen as of now in the code but we seem to be entertaining num_segs=0 in xhci_ring_alloc ) This should be backported to kernels as old as 2.6.31. Signed-off-by:
Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
commit 68aa95d5 upstream. This patch (as1489) works around a hardware bug in MosChip EHCI controllers. Evidently when one of these controllers increments the frame-index register, it changes the three low-order bits (the microframe counter) before changing the higher order bits (the frame counter). If the register is read at just the wrong time, the value obtained is too low by 8. When the appropriate quirk flag is set, we work around this problem by reading the frame-index register a second time if the first value's three low-order bits are all 0. This gives the hardware a chance to finish updating the register, yielding the correct value. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Jason N Pitt <jpitt@fhcrc.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Harro Haan authored
commit 276532ba upstream. The Kirkwood gave an unaligned memory access error on line 742 of drivers/usb/host/echi-hcd.c: "ehci->last_periodic_enable = ktime_get_real();" Signed-off-by:
Harro Haan <hrhaan@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Matthieu CASTET authored
commit 2093c6b4 upstream. This allow to clean duplicated code in most of SOC driver. Signed-off-by:
Matthieu CASTET <castet.matthieu@free.fr> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ning Jiang authored
commit 94abc56f upstream. The following patch removed uart_change_pm() in uart_resume_port(): commit 5933a161 Author: Yin Kangkai <kangkai.yin@linux.intel.com> serial-core: reset the console speed on resume It will break the pxa serial driver when the system resumes from suspend mode as it will try to set baud rate divider register in set_termios but with clock off. The register value can not be set correctly on some platform if the clock is disabled. The pxa driver will check the value and report the following warning: ------------[ cut here ]------------ WARNING: at drivers/tty/serial/pxa.c:545 serial_pxa_set_termios+0x1dc/0x250() Modules linked in: [<c0281f30>] (unwind_backtrace+0x0/0xf0) from [<c029341c>] (warn_slowpath_common+0x4c/0x64) [<c029341c>] (warn_slowpath_common+0x4c/0x64) from [<c029344c>] (warn_slowpath_null+0x18/0x1c) [<c029344c>] (warn_slowpath_null+0x18/0x1c) from [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) from [<c044a840>] (uart_resume_port+0x128/0x2dc) [<c044a840>] (uart_resume_port+0x128/0x2dc) from [<c044bbe0>] (serial_pxa_resume+0x18/0x24) [<c044bbe0>] (serial_pxa_resume+0x18/0x24) from [<c0454d34>] (platform_pm_resume+0x40/0x4c) [<c0454d34>] (platform_pm_resume+0x40/0x4c) from [<c0457ebc>] (pm_op+0x68/0xb4) [<c0457ebc>] (pm_op+0x68/0xb4) from [<c0458368>] (device_resume+0xb0/0xec) [<c0458368>] (device_resume+0xb0/0xec) from [<c04584c8>] (dpm_resume+0xe0/0x194) [<c04584c8>] (dpm_resume+0xe0/0x194) from [<c0458588>] (dpm_resume_end+0xc/0x18) [<c0458588>] (dpm_resume_end+0xc/0x18) from [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) from [<c02c5278>] (enter_state+0xac/0xdc) [<c02c5278>] (enter_state+0xac/0xdc) from [<c02c48ec>] (state_store+0xa0/0xbc) [<c02c48ec>] (state_store+0xa0/0xbc) from [<c0408f7c>] (kobj_attr_store+0x18/0x1c) [<c0408f7c>] (kobj_attr_store+0x18/0x1c) from [<c034a6a4>] (sysfs_write_file+0x108/0x140) [<c034a6a4>] (sysfs_write_file+0x108/0x140) from [<c02fb798>] (vfs_write+0xac/0x134) [<c02fb798>] (vfs_write+0xac/0x134) from [<c02fb8cc>] (sys_write+0x3c/0x68) [<c02fb8cc>] (sys_write+0x3c/0x68) from [<c027c700>] (ret_fast_syscall+0x0/0x2c) ---[ end trace 88289eceb4675b04 ]--- This patch fix the problem by adding the power on opertion back for uart console when console_suspend_enabled is true. Signed-off-by:
Ning Jiang <ning.jiang@marvell.com> Tested-by:
Mayank Rana <mrana@codeaurora.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Marcus Folkesson authored
commit e44aabd6 upstream. Errata E20: UART: Character Timeout interrupt remains set under certain software conditions. Implication: The software servicing the UART can be trapped in an infinite loop. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rigbert Hamisch authored
commit 1bfac90d upstream. add device ID for "HP un2430 Mobile Broadband Module" Signed-off-by:
Rigbert Hamisch <rigbert@gmx.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Richard Hartmann authored
commit 68c79e57 upstream. Simple patch to make qcserial recognize the USB id of the Sierra Wireless MC8355 which is based on the Gobi 3000 chip. Both UMTS and GPS work fine. Signed-off-by:
Richard Hartmann <richih.mailinglist@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Haiyang Zhang authored
commit c4b6a2ea upstream. netif_notify_peers() caused a kernel warning in netvsc_linkstatus_callback(), because netvsc_linkstatus_callback() is within IRQ context. So we move the first call to netif_notify_peers() into queued work as well, but with zero delay. In addition to "staging-next", this should also be back-ported to stable kernels 2.6.32 and later. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mike Sterling authored
commit cf55f4a8 upstream. If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc. Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue. Reported-by:
Robert Scheck <robert.scheck@etes.de> Signed-off-by:
Mike Sterling <mike.sterling@microsoft.com> Signed-off-by:
K.Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kautuk Consul authored
commit e8df1674 upstream. If the usermode app does an ioctl over this serial device by using TIOCMIWAIT, then the code will wait by setting the current task state to TASK_INTERRUPTIBLE and then calling schedule(). This will be woken up by the qt2_process_modem_status on URB completion when the port_extra->shadowMSR is set to the new modem status. However, this could result in a lost wakeup scenario due to a race in the logic in the qt2_ioctl(TIOCMIWAIT) loop and the URB completion for new modem status in qt2_process_modem_status. Due to this, the usermode app's task will continue to sleep despite a change in the modem status. Signed-off-by:
Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Bill Pemberton authored
commit 7cbf3c7c upstream. The serqt_usb2 driver will not work properly with the ssu100 device even though it claims to support it. The ssu100 is supported by the ssu100 driver in mainline so there is no need to have it claimed by serqt_usb2. Signed-off-by:
Bill Pemberton <wfp5p@virginia.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alexander Thomas authored
commit 7518b9b8 upstream. Revert changes in definitions that were submitted on May 11 2011 and committed on June 7 2011. No reason for the change in these values was given in the patch comment, it broke compatibility with older versions, and was difficult to detect by the simultaneous move of the lines of code. Signed-off-by:
Alexander Thomas <alexander.thomas@esaturnus.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jim Wylder authored
commit c5a48592 upstream. A return value of -EINPROGRESS from pm_runtime_get indicates that the device is already resuming due to a previous call. Internally, usb_autopm_get_interface_async doesn't treat this as an error and increments the usage count, but passes the error status along to the caller. The logical assumption of the caller is that any negative return value reflects the device not resuming and the pm_usage_cnt not being incremented. Since the usage count is being incremented and the device is resuming, return success (0) instead. Signed-off-by:
James Wylder <james.wylder@motorola.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit 1177c0ef upstream. Mistakenly, commit 64ba3dc3 (tty: never hold BTM while getting tty_mutex) switched one fail path in ptmx_open to not free the newly allocated tty. Fix that by jumping to the appropriate place. And rename the labels so that it's clear what is going on there. Introduced-in: v2.6.36-rc2 Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit fa90e1c9 upstream. If tty_add_file fails at the point it is now, we have to revert all the changes we did to the tty. It means either decrease all refcounts if this was a tty reopen or delete the tty if it was newly allocated. There was a try to fix this in v3.0-rc2 using tty_release in 0259894c (TTY: fix fail path in tty_open). But instead it introduced a NULL dereference. It's because tty_release dereferences filp->private_data, but that one is set even in our tty_add_file. And when tty_add_file fails, it's still NULL/garbage. Hence tty_release cannot be called there. To circumvent the original leak (and the current NULL deref) we split tty_add_file into two functions, making the latter non-failing. In that case we may do the former early in open, where handling failures is easy. The latter stays as it is now. So there is no change in functionality. The original bug (leak) was introduced by f573bd17 (tty: Remove __GFP_NOFAIL from tty_add_file()). Thanks Dan for reporting this. Later, we may split tty_release into more functions and call only some of them in this fail path instead. (If at all possible.) Introduced-in: v2.6.37-rc2 Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit c290f835 upstream. When tty_driver_lookup_tty fails in tty_open, we forget to drop a reference to the tty driver. This was added by commit 4a2b5fdd (Move tty lookup/reopen to caller). Fix that by adding tty_driver_kref_put to the fail path. I will refactor the code later. This is for the ease of backporting to stable. Introduced-in: v2.6.28-rc2 Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Pavel Shilovsky authored
commit 42274bb2 upstream. We should call cifs_all_info_to_fattr in rc == 0 case only. Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Pavel Shilovsky authored
commit 94443f43 upstream. ..the length field has only 17 bits. Acked-by:
Jeff Layton <jlayton@samba.org> Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 24 Oct, 2011 4 commits
-
-
Linus Torvalds authored
-
git://git.infradead.org/iommu-2.6Linus Torvalds authored
* git://git.infradead.org/iommu-2.6: intel-iommu: fix superpage support in pfn_to_dma_pte() intel-iommu: set iommu_superpage on VM domains to lowest common denominator intel-iommu: fix return value of iommu_unmap() API MAINTAINERS: Update VT-d entry for drivers/pci -> drivers/iommu move intel-iommu: Export a flag indicating that the IOMMU is used for iGFX. intel-iommu: Workaround IOTLB hang on Ironlake GPU intel-iommu: Fix AB-BA lockdep report
-
http://people.redhat.com/agk/git/linux-dmLinus Torvalds authored
* 'for-linus' of http://people.redhat.com/agk/git/linux-dm: dm kcopyd: fix job_pool leak
-
Takashi Iwai authored
Commit 4b239f45 ("x86-64, mm: Put early page table high") causes a S4 regression since 2.6.39, namely the machine reboots occasionally at S4 resume. It doesn't happen always, overall rate is about 1/20. But, like other bugs, once when this happens, it continues to happen. This patch fixes the problem by essentially reverting the memory assignment in the older way. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: <stable@kernel.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Yinghai Lu <yinghai.lu@oracle.com> [ We'll hopefully find the real fix, but that's too late for 3.1 now ] Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 23 Oct, 2011 1 commit
-
-
Alasdair G Kergon authored
Fix memory leak introduced by commit a6e50b40 (dm snapshot: skip reading origin when overwriting complete chunk). When allocating a set of jobs from kc->job_pool, job->master_job must be set (to point to itself) so that the mempool item gets freed when the master_job completes. master_job was introduced by commit c6ea41fb (dm kcopyd: preallocate sub jobs to avoid deadlock) Reported-by:
Michael Leun <ml@newton.leun.net> Cc: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com>
-