- 24 Nov, 2005 7 commits
-
-
Jim Keniston authored
Fix a bug in kprobes that can cause an Oops or even a crash when a return probe is installed on one of the following functions: sys_execve, do_execve, load_*_binary, flush_old_exec, or flush_thread. The fix is to remove the call to kprobe_flush_task() in flush_thread(). This fix has been tested on all architectures for which the return-probes feature has been implemented (i386, x86_64, ppc64, ia64). Please apply. BACKGROUND Up to now, we have called kprobe_flush_task() under two situations: when a task exits, and when it execs. Flushing kretprobe_instances on exit is correct because (a) do_exit() doesn't return, and (b) one or more return-probed functions may be active when a task calls do_exit(). Neither is the case for sys_execve() and its callees. Initially, the mistaken call to kprobe_flush_task() on exec was harmless because we put the "real" return address of each active probed function back in the stack, just to be safe, when we recycled its kretprobe_instance. When support for ppc64 and ia64 was added, this safety measure couldn't be employed, and was eventually dropped even for i386 and x86_64. sys_execve() and its callees were informally blacklisted for return probes until this fix was developed. Acked-by:
Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by:
Jim Keniston <jkenisto@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Hugh Dickins authored
alpha, sparc64, x86_64 are each missing some primitives from their atomic64 support: fill in the gaps I've noticed by extrapolating asm, follow the groupings in each file. But powerpc and parisc still lack atomic64. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: "David S. Miller" <davem@davemloft.net> Cc: Andi Kleen <ak@muc.de> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Hugh Dickins authored
Restore an earlier mod which went missing in the powerpc reshuffle: the 4xx mmu_mapin_ram does not need to take init_mm.page_table_lock. Signed-off-by:
-
Hugh Dickins authored
Update comments (only) on page_table_lock and mmap_sem in arch/powerpc. Removed the comment on page_table_lock from hash_huge_page: since it's no longer taking page_table_lock itself, it's irrelevant whether others are; but how it is safe (even against huge file truncation?) I can't say. Signed-off-by:
-
Hugh Dickins authored
The follow_page changes in get_futex_key have left it with two almost identical blocks, when handling the rare case of a futex in a nonlinear vma. get_user_pages will itself do that follow_page, and its additional find_extend_vma is hardly any overhead since the vma is already cached. Let's just delete the follow_page block and let get_user_pages do it. Signed-off-by:
-
Hugh Dickins authored
Closer attention to the arithmetic shows that neither ppc64 nor sparc really uses one page for multiple page tables: how on earth could they, while pte_alloc_one returns just a struct page pointer, with no offset? Well, arm26 manages it by returning a pte_t pointer cast to a struct page pointer, harumph, then compensating in its pmd_populate. But arm26 is never SMP, so it's not a problem for split ptlock either. And the PA-RISC situation has been recently improved: CONFIG_PA20 works without the 16-byte alignment which inflated its spinlock_t. But the current union of spinlock_t with private does make the 7xxx struct page significantly larger, even without debug, so disable its split ptlock. Signed-off-by:
-
Andrew Morton authored
This fix causes problems on the very first floppy access - we haven't yet talked to the FDC so we don't know which state the write-protect tab is in. Revert for now. Signed-off-by:
-
- 23 Nov, 2005 5 commits
-
-
Matthew Wilcox authored
Most of the functions already check. Do the ones that didn't. Signed-off-by:
Matthew Wilcox <matthew@wil.cx> Signed-off-by:
-
Linus Torvalds authored
This reverts commit af2b4079 Changing the #define to an inline function breaks on non-SMP builds, since wuite a few places in the kernel do not implement the ipi handler when compiling for UP. Signed-off-by:
-
Linus Torvalds authored
The ext3 compat-ioctl translation wants to translate data structures that <linux/jbd.h> only declared when CONFIG_JBD was enabled. So make <linux/jbd.h> play nicely even when we don't actually end up using it. Acked-by:
Jeffrey Hundstad <jeffrey.hundstad@mnsu.edu> Acked-by:
Zan Lynx <zlynx@acm.org> Signed-off-by:
-
Linus Torvalds authored
There was some confusion about the different zone usage, this should fix up the resulting mess in the GFP zonemask handling. The different zone usage is still confusing (it's very easy to mix up the individual zone numbers with the GFP zone _list_ numbers), so we might want to clean up some of this in the future, but in the meantime this should fix the actual problems. Acked-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Linus Torvalds authored
-
- 22 Nov, 2005 28 commits
-
-
Adrian Bunk authored
"extern inline" doesn't make much sense. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Neil Horman authored
Patch to ifenslave so that under older ABI versions, a failure to propogate ip information from master to slave does not result in a filure to enslave the slave device. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Pablo Neira Ayuso authored
Remove proto == NULL checking since ip_conntrack_[nat_]proto_find_get always returns a valid pointer. Fix missing ip_conntrack_proto_put in some paths. Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Harald Welte <laforge@netfilter.org> Signed-off-by:
-
Jamal Hadi Salim authored
This patch fixes the problem with promoting aliases when: a) a single primary and > 1 secondary addresses b) multiple primary addresses each with at least one secondary address Based on earlier efforts from Brian Pomerantz <bapper@piratehaven.org>, Patrick McHardy <kaber@trash.net> and Thomas Graf <tgraf@suug.ch> Signed-off-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
-
Herbert Xu authored
Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Russell King authored
Not really a network problem, more a !SMP issue. net/core/flow.c:295: warning: statement with no effect flow.c:295: smp_call_function(flow_cache_flush_per_cpu, &info, 1, 0); Fix this by converting the macro to an inline function, which also increases the typechecking for !SMP builds. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Roman Zippel authored
This makes pkg-config now the prefered way to configure QT and properly fixes the recent Fedora breakage and leaves the old QT detection as fallback mechanism. Signed-off-by:
Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Jonathan E Brassow authored
The spinlock region_lock is held while calling mark_region which can sleep. Drop the spinlock before calling that function. A region's state and inclusion in the clean list are altered by rh_inc and rh_dec. The state variable is set to RH_CLEAN in rh_dec, but only if 'pending' is zero. It is set to RH_DIRTY in rh_inc, but not if it is already so. The changes to 'pending', the state, and the region's inclusion in the clean list need to be atomicly. Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
jblunck@suse.de authored
bio_list_merge() should do nothing if the second list is empty - not oops. Signed-off-by:
-
Stefan Bader authored
do_end_io() can be called without interrupts blocked. Signed-off-by:
-
Alasdair G Kergon authored
The linux bitset operators (test_bit, set_bit etc) work on arrays of "unsigned long". dm-log uses such bitsets but treats them as arrays of uint32_t, only allocating and zeroing a multiple of 4 bytes (as 'clean_bits' is a uint32_t). The patch below fixes this problem. The problem is specific to 64-bit big endian machines such as s390x or ppc-64 and can prevent pvmove terminating. In the simplest case, if "region_count" were (say) 30, then bitset_size (below) would be 4 and bitset_uint32_count would be 1. Thus the memory for this butset, after allocation and zeroing would be 0 0 0 0 X X X X On a bigendian 64bit machine, bit 0 for this bitset is in the 8th byte! (and every bit that dm-log would use would be in the X area). 0 0 0 0 X X X X ^ here which hasn't been cleared properly. As the dm-raid1 code only syncs and counts regions which have a 0 in the 'sync_bits' bitset, and only finishes when it has counted high enough, a large number of 1's among those 'X's will cause the sync to not complete. It is worth noting that the code uses the same bitsets for in-memory and on-disk logs. As these bitsets are host-endian and host-sized, this means that they cannot safely be moved between computers with Signed-off-by:Neil Brown <neilb@suse.de> Signed-off-by:
-
Alasdair G Kergon authored
In some circumstances the LIST_VERSIONS output is truncated because the size calculation forgets about a 'uint32_t' in each structure - but the inclusion of the whole of ALIGN_MASK frequently compensates for the omission. This is a quick workaround to use an upper bound. (The code ought to be fixed to supply the actual size.) Running 'dmsetup targets' may demonstrate the problem: when I run it, the last line comes out as 'erro' instead of 'error'. Consequently, 'lvcreate --type error' doesn't work. Signed-off-by:
-
Kiyoshi Ueda authored
An error path in table_load() forgets to release a table that won't now be referenced. Signed-off-by:
-
Randy Dunlap authored
Correct lots of URLs in Documentation/ Also a few minor whitespace cleanups and typo/spello fixes. Sadly there are still a lot of bad URLs remaining. Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Dave Jones authored
This driver only appears on IA32 & EM64T boxes. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Matthew Dobson authored
scsi_get_command() attempts to write into a structure that may not have been successfully allocated. Move this write inside the if statement that ensures we won't panic the kernel with a NULL pointer dereference. Signed-off-by:
Matthew Dobson <colpatch@us.ibm.com> Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by:
-
Grant Coady authored
drivers/cpufreq/cpufreq.c: In function `cpufreq_remove_dev': drivers/cpufreq/cpufreq.c:696: warning: unused variable `cpu_sys_dev' Signed-off-by:
Grant Coady <gcoady@gmail.com> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
-
Eric Paris authored
If there are multiple updaters to /proc/sys/vm/nr_hugepages simultaneously it is possible for the nr_huge_pages variable to become incorrect. There is no locking in the set_max_huge_pages function around alloc_fresh_huge_page which is able to update nr_huge_pages. Two callers to alloc_fresh_huge_page could race against each other as could a call to alloc_fresh_huge_page and a call to update_and_free_page. This patch just expands the area covered by the hugetlb_lock to cover the call into alloc_fresh_huge_page. I'm not sure how we could say that a sysctl section is performance critical where more specific locking would be needed. My reproducer was to run a couple copies of the following script simultaneously while [ true ]; do echo 1000 > /proc/sys/vm/nr_hugepages echo 500 > /proc/sys/vm/nr_hugepages echo 750 > /proc/sys/vm/nr_hugepages echo 100 > /proc/sys/vm/nr_hugepages echo 0 > /proc/sys/vm/nr_hugepages done and then watch /proc/meminfo and eventually you will see things like HugePages_Total: 100 HugePages_Free: 109 After applying the patch all seemed well. Signed-off-by:
Eric Paris <eparis@redhat.com> Acked-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
Antonino A. Daplas authored
Reported by: Wayne E. Harlan "[1.] One line summary of the problem: When the kernel option "vga=1" is used, additional tty's (alt+control+Fx with x=2,3,4,5, etc) do not provide the full 50 lines of output. The first one does have 50 lines, however. [2.] Full description of the problem/report: These addtitional tty's show only 39 lines plus the top pixel of the 40-th line. The remaining lines are black and not shown. Kernel version 2.6.13.4 does not show this problem." This bug is caused by using a stale font height value on vgacon_init. Booting with vga=1 gives an 80x50 screen with an 8x8 font. Somewhere during the initialization, the font was changed to 8x9 and the first vc was correctly resized to 80x44. However, the rest of the vc's were not allocated yet, and when they were subsequently initialized, they still used a font height of 8 (instead of 9) causing the mentioned bug. Fix by saving the new font height to vga_video_font_height. Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Antonino A. Daplas authored
The shift value (amount to shift the bitmap so first pixel starts at origin(0,0)) is incorrect. This causes corrupted characters or a kernel crash if fontwidth is not divisible by 8 at 270 degrees, or fontheight not divisible by 8 at 180 degrees. Report and part of the fix contributed by Knut Petersen. Signed-off-by:
-
David Gibson authored
Currently, if a hugetlbfs is mounted without limits (the default), statfs() will return -1 for max/free/used blocks. This does not appear to be in line with normal convention: simple_statfs() and shmem_statfs() both return 0 in similar cases. Worse, it confuses the translation logic in put_compat_statfs(), causing it to return -EOVERFLOW on such a mount. This patch alters hugetlbfs_statfs() to return 0 for max/free/used blocks on a mount without limits. Note that we need the test in the patch below, rather than just using 0 in the sbinfo structure, because the -1 marked in the free blocks field is used internally to tell the Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
David Gibson authored
In fs/compat.c, whenever put_compat_statfs() returns an error, the containing syscall returns -EFAULT. This is presumably by analogy with the non-compat case, where any non-zero code from copy_to_user() should be translated into an EFAULT. However, put_compat_statfs() is also return -EOVERFLOW. The same applies for put_compat_statfs64(). This bug can be observed with a statfs() on a hugetlbfs directory. hugetlbfs, when mounted without limits reports available, free and total blocks as -1 (itself a bug, another patch coming). statfs() will mysteriously return EFAULT although it's parameters are perfectly valid addresses. This patch causes the compat versions of statfs() and statfs64() to correctly propogate the return values from put_compat_statfs() and put_compat_statfs64(). Signed-off-by:
-
Hugh Dickins authored
Earlier I unifdefed PageCompound, so that snd_pcm_mmap_control_nopage and others can give out a 0-order component of a higher-order page, which won't be mistakenly freed when zap_pte_range unmaps it. But many Bad page states reported a PG_reserved was freed after all: I had missed that we need to say __GFP_COMP to get compound page behaviour. Some of these higher-order pages are allocated by snd_malloc_pages, some by snd_malloc_dev_pages; or if SBUS, by sbus_alloc_consistent - but that has no gfp arg, so add __GFP_COMP into its sparc32/64 implementations. I'm still rather puzzled that DRM seems not to need a similar change. Signed-off-by:
-
Hugh Dickins authored
For copy_one_pte's print_bad_pte to show the task correctly (instead of "???"), dup_mmap must pass down parent vma rather than child vma. Signed-off-by:
-
Hugh Dickins authored
It used to be the case that PG_reserved pages were silently never freed, but in 2.6.15-rc1 they may be freed with a "Bad page state" message. We should work through such cases as they appear, fixing the code; but for now it's safer to issue the message without freeing the page, leaving PG_reserved set. Signed-off-by:
-
Hugh Dickins authored
It's strange enough to be looking out for anonymous pages in VM_UNPAGED areas, let's not insert the ZERO_PAGE there - though whether it would matter will depend on what we decide about ZERO_PAGE refcounting. But whereas do_anonymous_page may (exceptionally) be called on a VM_UNPAGED area, do_no_page should never be: just BUG_ON. Signed-off-by:
-
Hugh Dickins authored
copy_one_pte needs to copy the anonymous COWed pages in a VM_UNPAGED area, zap_pte_range needs to free them, do_wp_page needs to COW them: just like ordinary pages, not like the unpaged. But recognizing them is a little subtle: because PageReserved is no longer a condition for remap_pfn_range, we can now mmap all of /dev/mem (whether the distro permits, and whether it's advisable on this or that architecture, is another matter). So if we can see a PageAnon, it may not be ours to mess with (or may be ours from elsewhere in the address space). I suspect there's an entertaining insoluble self-referential problem here, but the page_is_anon function does a good practical job, and MAP_PRIVATE PROT_WRITE VM_UNPAGED will always be an odd choice. In updating the comment on page_address_in_vma, noticed a potential NULL dereference, in a path we don't actually take, but fixed it. Signed-off-by:
-
Hugh Dickins authored
Remove the BUG_ON(vma->vm_flags & VM_UNPAGED) from do_wp_page, and let it do Copy-On-Write without touching the VM_UNPAGED's page counts - but this is incomplete, because the anonymous page it inserts will itself need to be handled, here and in other functions - next patch. We still don't copy the page if the pfn is invalid, because the copy_user_highpage interface does not allow it. But that's not been a problem in the past: can be added in later if the need arises. Signed-off-by:
-
