- 02 May, 2007 26 commits
-
-
Christoph Lameter authored
NR_FILE_PAGES must be accounted for depending on the zone that the page belongs to. If we replace the page in the radix tree then we may have to shift the count to another zone. Suggested-by:
Ethan Solomita <solo@google.com> Cc: Martin Bligh <mbligh@mbligh.org> Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Taku Izumi authored
I encountered the following kernel panic. The cause of this problem was NULL pointer access in check_modem_status() in 8250.c. I confirmed this problem is fixed by the attached patch, but I don't know this is the correct fix. sadc[4378]: NaT consumption 2216203124768 [1] Modules linked in: binfmt_misc dm_mirror dm_mod thermal processor fan container button sg e100 eepro100 mii ehci_hcd ohci_hcd Pid: 4378, CPU 0, comm: sadc psr : 00001210085a2010 ifs : 8000000000000289 ip : [<a000000100482071>] Not tainted ip is at check_modem_status+0xf1/0x360 unat: 0000000000000000 pfs : 0000000000000289 rsc : 0000000000000003 rnat: 800000000000cc18 bsps: 0000000000000000 pr : 0000000000aa6a99 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a000000100481fb0 b6 : a0000001004822e0 b7 : a000000100477f20 f6 : 1003e2222222222222222 f7 : 0ffdba200000000000000 f8 : 100018000000000000000 f9 : 10002a000000000000000 f10 : 0fffdccccccccc8c00000 f11 : 1003e0000000000000000 r1 : a000000100b9af40 r2 : 0000000000000008 r3 : a000000100ad4e21 r8 : 00000000000000bb r9 : 0000000000000001 r10 : 0000000000000000 r11 : a000000100ad4d58 r12 : e0000000037b7df0 r13 : e0000000037b0000 r14 : 0000000000000001 r15 : 0000000000000018 r16 : a000000100ad4d6c r17 : 0000000000000000 r18 : 0000000000000000 r19 : 0000000000000000 r20 : a00000010099bc88 r21 : 00000000000000bb r22 : 00000000000000bb r23 : c003fffffc0ff3fe r24 : c003fffffc000000 r25 : 00000000000ff3fe r26 : a0000001009b7ad0 r27 : 0000000000000001 r28 : a0000001009b7ad8 r29 : 0000000000000000 r30 : a0000001009b7ad0 r31 : a0000001009b7ad0 Call Trace: [<a000000100013940>] show_stack+0x40/0xa0 sp=e0000000037b7810 bsp=e0000000037b1118 [<a0000001000145a0>] show_regs+0x840/0x880 sp=e0000000037b79e0 bsp=e0000000037b10c0 [<a0000001000368e0>] die+0x1c0/0x2c0 sp=e0000000037b79e0 bsp=e0000000037b1078 [<a000000100036a30>] die_if_kernel+0x50/0x80 sp=e0000000037b7a00 bsp=e0000000037b1048 [<a000000100037c40>] ia64_fault+0x11e0/0x1300 sp=e0000000037b7a00 bsp=e0000000037b0fe8 [<a00000010000bdc0>] ia64_leave_kernel+0x0/0x280 sp=e0000000037b7c20 bsp=e0000000037b0fe8 [<a000000100482070>] check_modem_status+0xf0/0x360 sp=e0000000037b7df0 bsp=e0000000037b0fa0 [<a000000100482300>] serial8250_get_mctrl+0x20/0xa0 sp=e0000000037b7df0 bsp=e0000000037b0f80 [<a000000100478170>] uart_read_proc+0x250/0x860 sp=e0000000037b7df0 bsp=e0000000037b0ee0 [<a0000001001c16d0>] proc_file_read+0x1d0/0x4c0 sp=e0000000037b7e10 bsp=e0000000037b0e80 [<a0000001001394b0>] vfs_read+0x1b0/0x300 sp=e0000000037b7e20 bsp=e0000000037b0e30 [<a000000100139cd0>] sys_read+0x70/0xe0 sp=e0000000037b7e20 bsp=e0000000037b0db0 [<a00000010000bc20>] ia64_ret_from_syscall+0x0/0x20 sp=e0000000037b7e30 bsp=e0000000037b0db0 [<a000000000010620>] __kernel_syscall_via_break+0x0/0x20 sp=e0000000037b8000 bsp=e0000000037b0db0 Fix the possible NULL pointer access in check_modem_status() in 8250.c. The check_modem_status() would access 'info' member of uart_port structure, but it is not initialized before uart_open() is called. The check_modem_status() can be called through /proc/tty/driver/serial before uart_open() is called. Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
Taku Izumi <izumi2005@soft.fujitsu.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Hugh Dickins authored
I only have CONFIG_NUMA=y for build testing: surprised when trying a memhog to see lots of other processes killed with "No available memory (MPOL_BIND)". memhog is killed correctly once we initialize nodemask in constrained_alloc(). Signed-off-by:
Hugh Dickins <hugh@veritas.com> Acked-by:
William Irwin <bill.irwin@oracle.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
While digging through my MAP_FIXED changes, I found that rather obvious bug in /dev/mem mmap implementation for nommu archs. get_unmapped_area() is expected to return an address, not a pfn. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-By:
David Howells <dhowells@redhat.com> Signed-off-by:
-
James Bottomley authored
3w-xxxx emulates a REQUEST_SENSE response by simply returning nothing. Unfortunately, it's assuming that the REQUEST_SENSE command is implemented with use_sg == 0, which is no longer the case. The oops occurs because it's clearing the scatterlist in request_buffer instead of the memory region. This is fixed by using tw_transfer_internal() to transfer correctly to the scatterlist. Acked-by:
adam radford <aradford@gmail.com> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Michal Januszewski authored
[PATCH] vt: fix potential race in VT_WAITACTIVE handler On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0 if fg_console has already been updated in redraw_screen() but the console switch itself hasn't been completed. Fix this by checking fg_console in vt_waitactive() with the console sem held. Signed-off-by:
Michal Januszewski <spock@gentoo.org> Acked-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Zwane Mwaikambo authored
[PATCH] x86: Don't probe for DDC on VBE1.2 VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst uncompressing kernel with some video cards. Make sure we check VBE version before fiddling around with DDC. http://bugzilla.kernel.org/show_bug.cgi?id=1458 Opened: 2003-10-30 09:12 Last update: 2007-02-13 22:03 Much thanks to Tobias Hain for help in testing and investigating the bug. Tested on; i386, Chips & Technologies 65548 VESA VBE 1.2 CONFIG_VIDEO_SELECT=Y CONFIG_FIRMWARE_EDID=Y Untested on x86_64. Signed-off-by:
Zwane Mwaikambo <zwane@infradead.org> Signed-off-by:
Andi Kleen <ak@suse.de> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Trond Myklebust authored
NFS: Fix an Oops in nfs_setattr() It looks like nfs_setattr() and nfs_rename() also need to test whether the target is a regular file before calling nfs_wb_all()... Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Alan Cox authored
exec.c: fix coredump to pipe problem and obscure "security hole" The patch checks for "|" in the pattern not the output and doesn't nail a pid on to a piped name (as it is a program name not a file) Also fixes a very very obscure security corner case. If you happen to have decided on a core pattern that starts with the program name then the user can run a program called "|myevilhack" as it stands. I doubt anyone does this. Signed-off-by:
Alan Cox <alan@redhat.com> Confirmed-by:
Christopher S. Aker <caker@theshore.net> Signed-off-by:
-
Badari Pulavarty authored
cache_k8_northbridges() overflows beyond allocation cache_k8_northbridges() is storing config values to incorrect locations (in flush_words) and also its overflowing beyond the allocation, causing slab verification failures. Signed-off-by:
Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
-
Olaf Kirch authored
This fixes and OOPS due to incorrect socket orpahning in the IRDA stack. [IrDA]: Correctly handling socket error This patch fixes an oops first reported in mid 2006 - see http://lkml.org/lkml/2006/8/29/358 The cause of this bug report is that when an error is signalled on the socket, irda_recvmsg_stream returns without removing a local wait_queue variable from the socket's sk_sleep queue. This causes havoc further down the road. In response to this problem, a patch was made that invoked sock_orphan on the socket when receiving a disconnect indication. This is not a good fix, as this sets sk_sleep to NULL, causing applications sleeping in recvmsg (and other places) to oops. This is against the latest net-2.6 and should be considered for -stable inclusion. Signed-off-by:
Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Aubrey.Li authored
Netpoll UDP input handler needs to pull up the UDP headers and handle receive checksum offloading properly just like the normal UDP input path does else we get corrupted checksums. [NET]: Fix UDP checksum issue in net poll mode. In net poll mode, the current checksum function doesn't consider the kind of packet which is padded to reach a specific minimum length. I believe that's the problem causing my test case failed. The following patch fixed this issue. Signed-off-by:
Aubrey.Li <aubreylee@gmail.com> Signed-off-by:
-
John Heffner authored
In 2.6.18 a change was made to the tcp_mem[] calculations, but this causes regressions for some folks up to 2.6.20 The following fix to smooth out the calculation from the pending 2.6.21 tree by John Heffner fixes the problem for these folks. [TCP]: Fix tcp_mem[] initialization. Change tcp_mem initialization function. The fraction of total memory is now a continuous function of memory size, and independent of page size. Signed-off-by:
John Heffner <jheffner@psc.edu> Signed-off-by:
-
Tom "spot" Callaway authored
[SPARC64]: Fix inline directive in pci_iommu.c While building a test kernel for the new esp driver (against git-current), I hit this bug. Trivial fix, put the inline declaration in the right place. :) Signed-off-by:
Tom "spot" Callaway <tcallawa@redhat.com> Signed-off-by:
-
David Miller authored
The 32-bit syscall trampoline for sys_ipc() on sparc64 was sign extending various arguments, which is bogus when using compat_sys_ipc() since that function expects zero extended copies of all the arguments. This bug breaks the sparc64 kernel when built with gcc-4.2.x among other things. [SPARC64]: Fix arg passing to compat_sys_ipc(). Do not sign extend args using the sys32_ipc stub, that is buggy and unnecessary. Based upon an excellent report by Mikael Pettersson. Signed-off-by:
-
David Miller authored
[SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something. We only map DMA when cmd->request_bufflen is non-zero for non-sg buffers, we thus should make the same check when unmapping. Based upon a report from Pasi Pirhonen. Signed-off-by:
-
David Miller authored
[SPARC64]: Fix SBUS IOMMU allocation code. There are several IOMMU allocator bugs. Instead of trying to fix this overly complicated code, just mirror the PCI IOMMU arena allocator which is very stable and well stress tested. I tried to make the code as identical as possible so we can switch sun4u PCI and SBUS over to a common piece of IOMMU code. All that will be need are two callbacks, one to do a full IOMMU flush and one to do a streaming buffer flush. This patch gets rid of a lot of hangs and mysterious crashes on SBUS sparc64 systems, at least for me. Signed-off-by:
-
Hugh Dickins authored
sys_madvise has down_write of mmap_sem, then madvise_remove calls vmtruncate_range which takes i_mutex and i_alloc_sem: no, we can easily devise deadlocks from that ordering. madvise_remove drop mmap_sem while calling vmtruncate_range: luckily, since madvise_remove doesn't split or merge vmas, it's easy to handle this case with a NULL prev, without restructuring sys_madvise. (Though sad to retake mmap_sem when it's unlikely to be needed, and certainly down_read is sufficient for MADV_REMOVE, unlike the other madvices.) Signed-off-by:
-
Hugh Dickins authored
shmem_truncate_range has its own truncate_inode_pages_range, to free any pages racily instantiated while it was in progress: a SHMEM_PAGEIN flag is set when this might have happened. But holepunching gets no chance to clear that flag at the start of vmtruncate_range, so it's always set (unless a truncate came just before), so holepunch almost always does this second truncate_inode_pages_range. shmem holepunch has unlikely swap<->file races hereabouts whatever we do (without a fuller rework than is fit for this release): I was going to skip the second truncate in the punch_hole case, but Miklos points out that would make holepunch correctness more vulnerable to swapoff. So keep the second truncate, but follow it by an unmap_mapping_range to eliminate the disconnected pages (freed from pagecache while still mapped in userspace) that it might have left behind. Signed-off-by:
-
Hugh Dickins authored
Miklos Szeredi observes that during truncation of shmem page directories, info->lock is released to improve latency (after lowering i_size and next_index to exclude races); but this is quite wrong for holepunching, which receives no such protection from i_size or next_index, and is left vulnerable to races with shmem_unuse, shmem_getpage and shmem_writepage. Hold info->lock throughout when holepunching? No, any user could prevent rescheduling for far too long. Instead take info->lock just when needed: in shmem_free_swp when removing the swap entries, and whenever removing a directory page from the level above. But so long as we remove before scanning, we can safely skip taking the lock at the lower levels, except at misaligned start and end of the hole. Signed-off-by:
-
Hugh Dickins authored
Miklos Szeredi observes BUG_ON(!entry) in shmem_writepage() triggered in rare circumstances, because shmem_truncate_range() erroneously removes partially truncated directory pages at the end of the range: later reclaim on pages pointing to these removed directories triggers the BUG. Indeed, and it can also cause data loss beyond the hole. Fix this as in the patch proposed by Miklos, but distinguish between "limit" (how far we need to search: ignore truncation's next_index optimization in the holepunch case - if there are races it's more consistent to act on the whole range specified) and "upper_limit" (how far we can free directory pages: generally we must be careful to keep partially punched pages, but can relax at end of file - i_size being held stable by i_mutex). Signed-off-by:
-
Avi Kivity authored
PAGE_MASK is an unsigned long, so using it to mask physical addresses on i386 (which are 64-bit wide) leads to truncation. This can result in page->private of unrelated memory pages being modified, with disasterous results. Fix by not using PAGE_MASK for physical addresses; instead calculate the correct value directly from PAGE_SIZE. Also fix a similar BUG_ON(). Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Avi Kivity authored
KVM shadow page tables are always in pae mode, regardless of the guest setting. This means that a guest pde (mapping 4MB of memory) is mapped to two shadow pdes (mapping 2MB each). When the guest writes to a pte or pde, we intercept the write and emulate it. We also remove any shadowed mappings corresponding to the write. Since the mmu did not account for the doubling in the number of pdes, it removed the wrong entry, resulting in a mismatch between shadow page tables and guest page tables, followed shortly by guest memory corruption. This patch fixes the problem by detecting the special case of writing to a non-pae pde and adjusting the address and number of shadow pdes zapped accordingly. Acked-by:
-
Jiri Kosina authored
HID: zeroing of bytes in output fields is bogus This patch removes bogus zeroing of unused bits in output reports, introduced in Simon's patch in commit d4ae650a. According to the specification, any sane device should not care about values of unused bits. What is worse, the zeroing is done in a way which is broken and might clear certain bits in output reports which are actually _used_ - a device that has multiple fields with one value of the size 1 bit each might serve as an example of why this is bogus - the second call of hid_output_report() would clear the first bit of report, which has already been set up previously. This patch will break LEDs on SpaceNavigator, because this device is broken and takes into account the bits which it shouldn't touch. The quirk for this particular device will be provided in a separate patch. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Michael S. Tsirkin authored
In mthca_arbel_fmr_unmap(), the high bits of the key are masked off. This gets rid of the effect of adjust_key(), which makes sure that bits 3 and 23 of the key are equal when the Sinai throughput optimization is enabled, and so it may happen that an FMR will end up with bits 3 and 23 in the key being different. This causes data corruption, because when enabling the throughput optimization, the driver promises the HCA firmware that bits 3 and 23 of all memory keys will always be equal. Fix by re-applying adjust_key() after masking the key. Thanks to Or Gerlitz for reproducing the problem, and Ariel Shahar for help in debug. Signed-off-by:
Michael S. Tsirkin <mst@dev.mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
NeilBrown authored
sk_info_authunix is not being protected properly so the object that it points to can be cache_put twice, leading to corruption. We borrow svsk->sk_defer_lock to provide the protection. We should probably rename that lock to have a more generic name - later. Thanks to Gabriel for reporting this. Cc: Greg Banks <gnb@melbourne.sgi.com> Cc: Gabriel Barazer <gabriel@oxeva.fr> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
- 27 Apr, 2007 3 commits
-
-
Greg Kroah-Hartman authored
-
YOSHIFUJI Hideaki authored
[IPV6]: Fix thinko in ipv6_rthdr_rcv() changes. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Sergey Vlasov authored
[IPV4] nl_fib_lookup: Initialise res.r before fib_res_put(&res) When CONFIG_IP_MULTIPLE_TABLES is enabled, the code in nl_fib_lookup() needs to initialize the res.r field before fib_res_put(&res) - unlike fib_lookup(), a direct call to ->tb_lookup does not set this field. Signed-off-by:
Sergey Vlasov <vsu@altlinux.ru> Signed-off-by:
-
- 26 Apr, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
YOSHIFUJI Hideaki authored
[IPV6]: Disallow RH0 by default. A security issue is emerging. Disallow Routing Header Type 0 by default as we have been doing for IPv4. Note: We allow RH2 by default because it is harmless. Signed-off-by:
-
- 25 Apr, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Alexey Kuznetsov authored
[NETLINK]: Infinite recursion in netlink. Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel, which resulted in infinite recursion and stack overflow. The bug is present in all kernel versions since the feature appeared. The patch also makes some minimal cleanup: 1. Return something consistent (-ENOENT) when fib table is missing 2. Do not crash when queue is empty (does not happen, but yet) 3. Put result of lookup Signed-off-by:
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:
-
- 13 Apr, 2007 7 commits
-
-
Greg Kroah-Hartman authored
-
Chuck Ebbert authored
Update libata drive blacklist to the latest from 2.6.21 Removes one duplicate entry from blacklist table, adds several entries for drives with broken NCQ. [diff between 2.6.20 and 2.6.21-rc6, with one entry removed that required new libata features] Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Brian Pomerantz authored
When the dump cannot occur most likely because of a full file system and the page to be written is the zero page, the call to page_cache_release() is missed. Signed-off-by:
Brian Pomerantz <bapper@mvista.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: David Howells <dhowells@redhat.com> Cc: <stable@kernel.org> Signed-off-by:
-
Andrew Morton authored
Revert b46be050. Same reasoning as for ext3. Cc: Kirill Korotaev <dev@openvz.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ken Chen <kenneth.w.chen@intel.com> Cc: Andrey Savochkin <saw@sw.ru> Cc: <linux-ext4@vger.kernel.org> Cc: Dmitriy Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Andrew Morton authored
Revert e92a4d59. Dmitry points out "When we block_prepare_write() failed while ext3_prepare_write() we jump to "failure" label and call ext3_prepare_failure() witch search last mapped bh and invoke commit_write untill it. This is wrong!! because some bh from begining to the last mapped bh may be not uptodate. As a result we commit to disk not uptodate page content witch contains garbage from previous usage." and "Unexpected file size increasing." Call trace the same as it was in first issue but result is different. For example we have file with i_size is zero. we want write two blocks , but fs has only one free block. ->ext3_prepare_write(...from == 0, to == 2048) retry: ->block_prepare_write() == -ENOSPC# we failed but allocated one block here. ->ext3_prepare_failure() ->commit_write( from == 0, to == 1024) # after this i_size becomes 1024 :) if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries)) goto retry; Finally when all retries will be spended ext3_prepare_failure return -ENOSPC, but i_size was increased and later block trimm procedures can't help here. We don't appear to have the horsepower to fix these issues, so let's put things back the way they were for now. Cc: Kirill Korotaev <dev@openvz.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ken Chen <kenneth.w.chen@intel.com> Cc: Andrey Savochkin <saw@sw.ru> Cc: <linux-ext4@vger.kernel.org> Cc: Dmitriy Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Albert Lee authored
libata: Clear tf before doing request sense (take 3) patch 2/4: Clear tf before doing request sense. This fixes the AOpen 56X/AKH timeout problem. (http://bugzilla.kernel.org/show_bug.cgi?id=8244) Signed-off-by:
Albert Lee <albertcc@tw.ibm.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Mark Lord authored
2.6.21 fix lba48 bug in libata fill_result_tf() Current 2.6.21 libata does the following: void ata_tf_read(struct ata_port *ap, struct ata_taskfile *tf) { struct ata_ioports *ioaddr = &ap->ioaddr; tf->command = ata_check_status(ap); ... if (tf->flags & ATA_TFLAG_LBA48) { iowrite8(tf->ctl | ATA_HOB, ioaddr->ctl_addr); tf->hob_feature = ioread8(ioaddr->error_addr); ... } } ... static void fill_result_tf(struct ata_queued_cmd *qc) { struct ata_port *ap = qc->ap; ap->ops->tf_read(ap, &qc->result_tf); qc->result_tf.flags = qc->tf.flags; } Based on this, those last two statements fill_result_tf() appear to me to be in the wrong order, in that the tf->flags are uninitialized at the point where tf_read() is invoked. So for lba48 commands, tf_read() won't be reading back the full lba48 register contents.. Correct? This patch corrects fill_result_tf() so that the flags get copied to result_tf before they are used by tf_read(). Signed-off-by:Mark Lord <mlord@pobox.com> Signed-off-by:
-
