- 26 May, 2010 4 commits
-
-
Mel Gorman authored
commit 4a6018f7 upstream. Ordinarily, application using hugetlbfs will create mappings with reserves. For shared mappings, these pages are reserved before mmap() returns success and for private mappings, the caller process is guaranteed and a child process that cannot get the pages gets killed with sigbus. An application that uses MAP_NORESERVE gets no reservations and mmap() will always succeed at the risk the page will not be available at fault time. This might be used for example on very large sparse mappings where the developer is confident the necessary huge pages exist to satisfy all faults even though the whole mapping cannot be backed by huge pages. Unfortunately, if an allocation does fail, VM_FAULT_OOM is returned to the fault handler which proceeds to trigger the OOM-killer. This is unhelpful. Even without hugetlbfs mounted, a user using mmap() can trivially trigger the OOM-killer because VM_FAULT_OOM is returned (will provide example program if desired - it's a whopping 24 lines long). It could be considered a DOS available to an unprivileged user. This patch alters hugetlbfs to kill a process that uses MAP_NORESERVE where huge pages were not available with SIGBUS instead of triggering the OOM killer. This change affects hugetlb_cow() as well. I feel there is a failure case in there, but I didn't create one. It would need a fairly specific target in terms of the faulting application and the hugepage pool size. The hugetlb_no_page() path is much easier to hit but both might as well be closed. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: David Rientjes <rientjes@google.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Hennerich authored
commit de145b44 upstream. The current allocation does not include the memory required for blanking lines. So avoid memory corruption when multiple devices are using the DMA memory near each other. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Oliver Neukum authored
commit 06efbeb4 upstream. The work queue has to be flushed after the device has been made inaccessible. The patch closes a window during which a work queue might remain active after the device is removed and would then lead to ACPI calls with undefined behavior. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Acked-by:
Eric Piel <eric.piel@tremplin-utc.net> Acked-by:
Pavel Machek <pavel@ucw.cz> Cc: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by:
-
Bjørn Mork authored
commit ccc2d97c upstream. commit 2783ef23 moved the initialisation of saddr and daddr after pskb_may_pull() to avoid a potential data corruption. Unfortunately also placing it after the short packet and bad checksum error paths, where these variables are used for logging. The result is bogus output like [92238.389505] UDP: short packet: From 2.0.0.0:65535 23715/178 to 0.0.0.0:65535 Moving the saddr and daddr initialisation above the error paths, while still keeping it after the pskb_may_pull() to keep the fix from commit 2783ef23. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
- 12 May, 2010 36 commits
-
-
Greg Kroah-Hartman authored
This reverts commit d150a2b9. Thanks to Jiri Benc for finding the problem that this patch is not correct for the 2.6.32-stable series. Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Greg Kroah-Hartman authored
-
Ralf Baechle authored
(cherry picked from commit e65c7f33d75e977350ca350573d93c517ec02776) Previously it was unconditionally used on all Sibyte family SOCs. The M3 bug has to be handled in the TLB exception handler which is extremly performance sensitive, so this modification is expected to deliver around 2-3% performance improvment. This is important as required changes to the M3 workaround will make it more costly. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
James Bottomley authored
commit 77a42297 upstream. There's nastyness in the way we currently handle barriers (and discards): They're effectively filesystem commands, but they get processed as BLOCK_PC commands. Unfortunately BLOCK_PC commands are taken by SCSI to be SG_IO commands and the issuer expects to see and handle any returned errors, however trivial. This leads to a huge problem, because the block layer doesn't expect this to happen and any trivially retryable error on a barrier causes an immediate I/O error to the filesystem. The only real way to hack around this is to take the usual class of offending errors (unit attentions) and make them all retryable in the case of a REQ_HARDBARRIER. A correct fix would involve a rework of the entire block and SCSI submit system, and so is out of scope for a quick fix. Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Hannes Reinecke authored
commit c213e140 upstream. Some arrays are giving I/O errors with ext3 filesystems when SYNCHRONIZE_CACHE gets a UNIT_ATTENTION. What is happening is that these commands have no retries, so the UNIT_ATTENTION causes the barrier to fail. We should be enable retries here to clear any transient error and allow the barrier to succeed. Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Douglas Gilbert authored
commit 5447ed6c upstream. In the scsi_debug driver, the virtual_gb option ignores the sector_size, implicitly assuming that is 512 bytes. So if 'virtual_gb=1 sector_size=4096' the result is an 8 GB (virtual) disk. Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Mike Christie authored
commit 96b1f96d upstream. This fixes a regression introduced with this commit: commit d3305f34 Author: Mike Christie <michaelc@cs.wisc.edu> Date: Thu Aug 20 15:10:58 2009 -0500 [SCSI] libiscsi: don't increment cmdsn if cmd is not sent in 2.6.32. When I moved the hdr->cmdsn after init_task, I added a bug when header digests are used. The problem is that the LLD may calculate the header digest in init_task, so if we then set the cmdsn after the init_task call we change what the digest will be calculated by the target. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Tejun Heo authored
commit 70b25f89 upstream. blk_abort_request() expects queue lock to be held by the caller. Grab it before calling the function. Lack of this synchronization led to infinite loop on corrupt q->timeout_list. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Jakob Viketoft authored
commit ccb8d8d0 upstream. The use of mfp_cfg_t causes build errors without including <mach/mfp.h>. CC: Daniel Mack <daniel@caiaq.de> Signed-off-by:
Jakob Viketoft <jakob.viketoft@bitsim.com> Signed-off-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Arjan van de Ven authored
commit 1c6fe036 upstream. commit 672917dc ("cpuidle: menu governor: reduce latency on exit") added an optimization, where the analysis on the past idle period moved from the end of idle, to the beginning of the new idle. Unfortunately, this optimization had a bug where it zeroed one key variable for new use, that is needed for the analysis. The fix is simple, zero the variable after doing the work from the previous idle. During the audit of the code that found this issue, another issue was also found; the ->measured_us data structure member is never set, a local variable is always used instead. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: Corrado Zoccolo <czoccolo@gmail.com> Signed-off-by:
-
Kamal Mostafa authored
commit ea5bc73f upstream. Add Dell Studio models (1558, 1557, 1555) to the 'set_sci_en_on_resume' list to fix hang on resume. BugLink: http://bugs.launchpad.net/bugs/553498Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Alex Chiang <achiang@canonical.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Dan Carpenter authored
commit 18262714 upstream. acpi_device_class can only be 19 characters and a NULL terminator. The current code has a buffer overflow in acpi_power_meter_add(): strcpy(acpi_device_class(device), ACPI_POWER_METER_CLASS); Signed-off-by:
Dan Carpenter <error27@gmail.com> Cc: Len Brown <lenb@kernel.org> Cc: "Darrick J. Wong" <djwong@us.ibm.com> Signed-off-by:
-
Alex Chiang authored
commit 07bedca2 upstream. Multiple Lenovo ThinkPad models with Intel Core i5/i7 CPUs can successfully suspend/resume once, and then hang on the second s/r cycle. We got confirmation that this was due to a BIOS defect. The BIOS did not properly set SCI_EN coming out of S3. The BIOS guys hinted that The Other Leading OS ignores the fact that hardware owns the bit and sets it manually. In any case, an existing DMI table exists for machines where this defect is a known problem. Lenovo promise to fix their BIOS, but for folks who either won't or can't upgrade their BIOS, allow Linux to workaround the issue. https://bugzilla.kernel.org/show_bug.cgi?id=15407 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374 Confirmed by numerous testers in the launchpad bug that using acpi_sleep=sci_force_enable fixes the issue. We add the machines to acpisleep_dmi_table[] to automatically enable this workaround. Cc: Colin King <colin.king@canonical.com> Signed-off-by:
-
Bjørn Mork authored
commit 6f550dc0 upstream. Never call dvb_frontend_detach if we failed to attach a frontend. This fixes the following oops, which will be triggered by a missing stv090x module: [ 8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI) [ 8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29 [ 8.328665] Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 8.328753] Intel ICH 0000:00:1f.5: setting latency timer to 64 [ 8.562047] DVB: Unable to find symbol stv090x_attach() [ 8.562117] BUG: unable to handle kernel NULL pointer dereference at 000000ac [ 8.562239] IP: [<e08b04a3>] dvb_frontend_detach+0x4/0x67 [dvb_core] Ref http://bugs.debian.org/575207Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Gabriele A. Trombetti authored
commit 87aa6300 upstream. Fix: Raid-6 was not trying to correct a read-error when in singly-degraded state and was instead dropping one more device, going to doubly-degraded state. This patch fixes this behaviour. Tested-by:
Janos Haar <janos.haar@netcenter.hu> Signed-off-by:
Gabriele A. Trombetti <g.trombetti.lkrnl1213@logicschema.com> Reported-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Stijn Tintel authored
commit e2dbe06c upstream. Move initialization of the virtio framework before the initialization of mtd, so that block2mtd can be used on virtio-based block devices. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15644Signed-off-by:
Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
NeilBrown authored
commit 1176568d upstream. Some time ago we stopped the clean/active metadata updates from being written to a 'spare' device in most cases so that it could spin down and say spun down. Device failure/removal etc are still recorded on spares. However commit 51d5668c broke this 50% of the time, depending on whether the event count is even or odd. The change log entry said: This means that the alignment between 'odd/even' and 'clean/dirty' might take a little longer to attain, how ever the code makes no attempt to create that alignment, so it could take arbitrarily long. So when we find that clean/dirty is not aligned with odd/even, force a second metadata-update immediately. There are already cases where a second metadata-update is needed immediately (e.g. when a device fails during the metadata update). We just piggy-back on that. Reported-by:
Joe Bryant <tenminjoe@yahoo.com> Signed-off-by:
-
Dan Carpenter authored
commit b338cc82 upstream. There is a typo here. We should be testing "*dentry" instead of "dentry". If "*dentry" is an ERR_PTR, it gets dereferenced in either mkdir() or create() which would cause an OOPs. Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Jeff Mahoney authored
commit 86c38a31 upstream. GCC 4.5 introduces behavior that forces the alignment of structures to use the largest possible value. The default value is 32 bytes, so if some structures are defined with a 4-byte alignment and others aren't declared with an alignment constraint at all - it will align at 32-bytes. For things like the ftrace events, this results in a non-standard array. When initializing the ftrace subsystem, we traverse the _ftrace_events section and call the initialization callback for each event. When the structures are misaligned, we could be treating another part of the structure (or the zeroed out space between them) as a function pointer. This patch forces the alignment for all the ftrace_event_call structures to 4 bytes. Without this patch, the kernel fails to boot very early when built with gcc 4.5. It's trivial to check the alignment of the members of the array, so it might be worthwhile to add something to the build system to do that automatically. Unfortunately, that only covers this case. I've asked one of the gcc developers about adding a warning when this condition is seen. Cc: stable@kernel.org Signed-off-by:
Jeff Mahoney <jeffm@suse.com> LKML-Reference: <4B85770B.6010901@suse.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Andreas Radke <a.radke@arcor.de> Signed-off-by:
-
Michael Chan authored
commit c441b8d2 upstream. It has been reported that under certain heavy traffic conditions in MSI-X mode, the driver can lose an MSI-X vector causing all packets in the associated rx/tx ring pair to be dropped. The problem is caused by the chip dropping the write to unmask the MSI-X vector by the kernel (when migrating the IRQ for example). This can be prevented by increasing the GRC timeout value for these register read and write operations. Thanks to Dell for helping us debug this problem. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Lalit Chandivade authored
commit 0f00a206 upstream. Correct issues where the lower scsi-status would be improperly cleared, instead, allow the midlayer to process the status after the proper residual-count checks are performed. Finally, validate firmware status flags prior to assigning values from the FCP_RSP frame. Signed-off-by:
Lalit Chandivade <lalit.chandivade@qlogic.com> Signed-off-by:
Michael Hernandez <michael.hernandez@qlogic.com> Signed-off-by:
Ravi Anand <ravi.anand@qlogic.com> Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Carlos O'Donell authored
commit 5fd4514b upstream. Set the PCI CLS early in the boot process to prevent device failures. In pcibios_set_master use the new pci_cache_line_size instead of a hard-coded value. Signed-off-by:
Carlos O'Donell <carlos@codesourcery.com> Reviewed-by:
Grant Grundler <grundler@google.com> Signed-off-by:
Kyle McMartin <kyle@redhat.com> Signed-off-by:
-
Dave Chinner authored
commit 9bf729c0 upstream On low memory boxes or those with highmem, kernel can OOM before the background reclaims inodes via xfssyncd. Add a shrinker to run inode reclaim so that it inode reclaim is expedited when memory is low. This is more complex than it needs to be because the VM folk don't want a context added to the shrinker infrastructure. Hence we need to add a global list of XFS mount structures so the shrinker can traverse them. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Alex Elder <aelder@sgi.com> Signed-off-by:
-
Andre Detsch authored
commit dc8bf1b1 upstream. tg3: Fix INTx fallback when MSI fails MSI setup changes the value of irq_vec in struct tg3 *tp. This attribute must be taken into account and restored before we try to do a new request_irq for INTx fallback. In powerpc, the original code was leading to an EINVAL return within request_irq, because the driver was trying to use the disabled MSI virtual irq number instead of tp->pdev->irq. Signed-off-by:
Andre Detsch <adetsch@br.ibm.com> Acked-by:
-
Douglas Gilbert authored
commit e7efe593 upstream. Further to the lsml thread titled: "does scsi_io_completion need to dump sense data for ata pass through (ck_cond = 1) ?" This is a patch to skip logging when the sense data is associated with a SENSE_KEY of "RECOVERED_ERROR" and the additional sense code is "ATA PASS-THROUGH INFORMATION AVAILABLE". This only occurs with the SAT ATA PASS-THROUGH commands when CK_COND=1 (in the cdb). It indicates that the sense data contains ATA registers. Smartmontools uses such commands on ATA disks connected via SAT. Periodic checks such as those done by smartd cause nuisance entries into logs that are: - neither errors nor warnings - pointless unless the cdb that caused them are also logged Signed-off-by:
-
Matthew Garrett authored
commit cc2893b6 upstream. If the firmware puts a device back into D0 state at resume time, we'll update its state in resume_noirq and thus skip the platform resume code. Calling that code twice should be safe and we ought to avoid getting to that point anyway, so remove the check and also allow the platform pci code to be called for D0. Fixes USB not being powered after resume on recent Lenovo machines. Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
françois romieu authored
commit 908ba2bf upstream. 78f1cd02 ("fix broken register writes") does not work for Al Viro's r8169 (XID 18000000). Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Francois Romieu authored
commit 78f1cd02 upstream. This is quite similar to b39fe41f though said registers are not even documented as 64-bit registers - as opposed to the initial TxDescStartAddress ones - but as single bytes which must be combined into 32 bits at the MMIO read/write level before being merged into a 64 bit logical entity. Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR registers (aka "multicast is broken for ages on ARM) and to Timo Teräs <timo.teras@iki.fi> for the MAC registers. Signed-off-by:
-
David Dillow authored
commit 4c020a96 upstream. r8169 needs certain writes to be visible to other CPUs or the NIC before touching the hardware, but was using smp_wmb() which is only required to order cacheable memory access. Switch to wmb() which is required to order both cacheable and non-cacheable memory. Noticed by Catalin Marinas and Paul Mackerras. Signed-off-by:
David Dillow <dave@thedillows.org> Signed-off-by:
-
Wufei authored
commit 56151e75 upstream. The bypassing of this test is a leftover from 2.4 vintage kernels, and is no longer appropriate, or even used by KGDB. Currently KGDB uses probe_kernel_write() for all access to memory via the KGDB core, so it can simply be deleted. This fixes CVE-2010-1446. CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Paul Mackerras <paulus@samba.org> CC: Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Wufei <fei.wu@windriver.com> Signed-off-by:
Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
-
Marcelo Tosatti authored
Commit 78ce64a3 in v2.6.32.12 introduced a warning due to unused load_segment_descriptor_to_kvm_desct helper, which has been opencoded by this commit. On upstream, the helper was removed as part of a different commit. Remove the now unused function. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Neil Horman authored
commit 38ff3e6b upstream. This was just recently reported to me. When built as modules, the dccp_probe module has a silent dependency on the dccp module. This stems from the fact that the module_init routine of dccp_probe registers a jprobe on the dccp_sendmsg symbol. Since the symbol is only referenced as a text string (the .symbol_name field in the jprobe struct) rather than the address of the symbol itself, depmod never picks this dependency up, and so if you load the dccp_probe module without the dccp module loaded, the register_jprobe call fails with an -EINVAL, and the whole module load fails. The fix is pretty easy, we can just wrap the register_jprobe call in a try_then_request_module call, which forces the dependency to get satisfied prior to the probe registration. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Darren Jenkins authored
commit 088ea189 upstream. fix off by one error in the queue size check of p54_tx_qos_accounting_alloc() Coverity CID: 13314 Signed-off-by:
Darren Jenkins <darrenrjenkins@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Christian Lamparter authored
commit f5300e04 upstream. A long time ago, a user reported several crashes due to data corruptions which are likely the result of a not-100%-supported, or faulty? PCI bridge. ( http://patchwork.kernel.org/patch/53004/ ) This patch fixes entry #1. "1. p54p_check_rx_ring - skb_over_panic: Under a ping flood or just left running for a bit would panic with a skb_over_panic." As described in the mail: The invalid frame length causes skb_put to bailout and trigger a crash. Note: Simply dropping the frame is problematic, because if its content contains a tx feedback we would lose some portion of the device memory space.... And the driver/mac80211 should handle all other invalid data. Reported-by:
Quintin Pitts <geek4linux@gmail.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Zhang Rui authored
commit d7f0eea9 upstream. Introduce kernel parameter acpi_sleep=sci_force_enable some laptop requires SCI_EN being set directly on resume, or else they hung somewhere in the resume code path. We already have a blacklist for these laptops but we still need this option, especially when debugging some suspend/resume problems, in case there are systems that need this workaround and are not yet in the blacklist. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Acked-by:
-
Bill Pemberton authored
commit 2b0b3951 upstream. Resizing the filesystem would result in an diAllocExt error in some instances because changes in bmp->db_agsize would not get noticed if goto extendBmap was called. Signed-off-by:
Bill Pemberton <wfp5p@virginia.edu> Signed-off-by:
Dave Kleikamp <shaggy@linux.vnet.ibm.com> Cc: jfs-discussion@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
