history/include/asm-generic, branch master

[PATCH] consolidate asm/ipc.h

2005-03-31T00:38:00Z

All the asm*/ipc.h files are basically the same (for things that are used) so I have consolidated them all into asm-generic/ipc.h Signed-off-by: Stephen Rothwell Acked-By: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge whitespace and __nocast changes

2005-03-28T12:43:20Z

[PATCH] arch hook for notifying changes in PTE protections bits

2005-03-28T12:05:21Z

Recently on IA-64, we have found an issue where old data could be used by apps. The sequence of operations includes few mprotects from user space (glibc) goes like this: 1- The text region of an executable is mmaped using PROT_READ|PROT_EXEC. As a result, a shared page is allocated to user. 2- User then requests the text region to be mprotected with PROT_READ|PROT_WRITE. Kernel removes the execute permission and leave the read permission on the text region. 3- Subsequent write operation by user results in page fault and eventually resulting in COW break. User gets a new private copy of the page. At this point kernel marks the new page for defered flush. 4- User then request the text region to be mprotected back with PROT_READ|PROT_EXEC. mprotect suppport code in kernel, flushes the caches, updates the PTEs and then flushes the TLBs. Though after updating the PTEs with new permissions, we don't let the arch specific code know about the new mappings (through update_mmu_cache like routine). IA-64 typically uses update_mmu_cache to check for the defered flush flag (that got set in step 3) to maintain cache coherency lazily (The local I and D caches on IA-64 are incoherent). DavidM suggeested that we would need to add a hook in the function change_pte_range in mm/mprotect.c This would let the architecture specific code to look at the new ptes to decide if it needs to update any other architectual/kernel state based on the updated (new permissions) PTE values. We have added a new hook lazy_mmu_prot_update(pte_t) that gets called protection bits in PTEs change. This hook provides an opportunity to arch specific code to do needful. On IA-64 this will be used for lazily making the I and D caches coherent. Signed-off-by: David Mosberger Signed-off-by: Rohit Seth Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] posix-cpu-timers and cputime_t divisons.

2005-03-28T12:00:22Z

The posix cpu timers introduced code that will not work with an arbitrary type for cputime_t. In particular the division of two cputime_t values broke the s390 build because cputime_t is define as an unsigned long long. The first problem is the division of a cputime_t value by a number of threads. That is a cputime_t divided by an integer. The patch adds another macro cputime_div to the cputime macro regime which implements this type of division and replaces all occurences of a cputime / nthread in the posix cpu timer code. Next problem is bump_cpu_timer. This function is severly broken: 1) In the body of the first if statement a timer->it.cpu.incr.sched is used as the second argument of do_div. do_div expects an unsigned long as "base" parameter but timer->it.cpu.incr.sched is an unsigned long long. If the timer increment ever happens to be >= 2^32 the result is wrong and if the lower 32 bits are zero this even crashes with a fixed point divide exception. 2) The cputime_le(now.cpu, timer->it.cpu.expires.cpu) in the else if condition is wrong. The cputime_le() reads as "now.cpu <= timer->it.cpu.expires.cpu" and the subsequent cputime_ge() reads as "now.cpu >= timer.it.cpu.expires.cpu". That means that the two values needs to be equal to make the body of the second if to have any effect. The first cputime_le should be a cputime_ge. 3) timer->it.cpu.expires.cpu and delta in the else part of the if are of type cputime_t. A division of two cputime_t values is undefined (think of cputime_t as e.g. a struct timespec, that just doesn't work). We could add a primitive for this type of division but we'd end up with a 64 bit division or something even more complicated. The solution for bump_cpu_timer is to use the "slow" division algorithm that does shifts and subtracts. That adds yet another cputime macro, cputime_halve to do the right shift of a cputime value. The next problem is in arm_timer. The UPDATE_CLOCK macro does the wrong thing for it_prof_expires and it_virt_expires. Expanded the macro and added the cputime magic to it_prof/it_virt. The remaining problems are rather simple, timespec_to_jiffies instead of timespec_to_cputime and several cases where cputime_eq with cputime_zero needs to be used instead of "== 0". What still worries me a bit is to use "timer->it.cpu.incr.sched == 0" as check if the timer is armed at all. It should work but its not really clean. Signed-off-by: Martin Schwidefsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] mm counter operations through macros

2005-03-28T11:19:14Z

This patch extracts all the operations on counters protected by the page table lock (currently rss and anon_rss) into definitions in include/linux/sched.h. All rss operations are performed through the following macros: get_mm_counter(mm, member) -> Obtain the value of a counter set_mm_counter(mm, member, value) -> Set the value of a counter update_mm_counter(mm, member, value) -> Add to a counter inc_mm_counter(mm, member) -> Increment a counter dec_mm_counter(mm, member) -> Decrement a counter With this patch it becomes easier to add new counters and it is possible to redefine the method of counter handling. The counters are an issue for scalability since they are used in frequently used code paths and may cause cache line bouncing. F.e. One may not use counters at all and count the pages when needed, switch to atomic operations if the mm_struct locking changes or split the rss into counters that can be locally incremented. The relevant fields of the task_struct are renamed with a leading underscore to catch out people who are not using the acceessor macros. Signed-off-by: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Mark "gfp" masks as "unsigned int" and use __nocast to find violations.

2005-03-28T09:42:49Z

This makes it hard(er) to mix argument orders by mistake for things like kmalloc() and friends, since silent integer promotion is now caught by sparse.

[ARCH]: Consolidate portable unaligned.h implementations.

2005-03-17T05:54:31Z

Several architectures do their asm/unaligned.h support support by simply casting the pointer to a packed strcuture, then deref'ing that pointer. This forces gcc to assume the object is not aligned properly. This technique originated in Richard Henderson's asm-alpha/unaligned.h, IA64 uses the same technique as well. This works well on RISC systems for two reasons: 1) On systems like Alpha, MIPS, et al. which have special "load unaligned" instructions, GCC knows to emit them for code like this. 2) Even on systems without explicit unaligned load/store instruction support, the code emitted (basically, byte loads with shifts and ors) is about the same as what you get when emitting a memmove() call and you don't need the local stack slot. I was going to thus move asm-sparc64/unaligned.h over to such a scheme, but then I noticed that nobody actually includes the current memmove() based asm-generic/unaligned.h code. So why not put the portable packed structure implementation into asm-generic/unaligned.h and then make asm-{alpha,ia64,sparc64}/unaligned.h simply include that? I only had to make minor modifications to the alpha header when placing it into the generic area. In particular I had to convert some explicit "unsigned long", "unsigned int" et al. into the arch-agnostic "u64" "u32" etc. so that even 32-bit platforms could use this. Come to think of it I'll make sparc32 use this as well. I looked at all the other platform unaligned.h headers: I386/X86_64: can do unaligned loads directly ARM: is trying to be incredibly clever, and open codes the shifts and ors. I think it would be better if it used something similar to the packed structure technique. CRIS: like x86, can do unaligned stuff directly. FRV: needs help doing unaligned stuff, it probably also could use the packed structure stuff. H8300: needs help, could use this new asm-generic/unaligned.h header M32R: likewise M68K: can do unaligned access directly. MIPS: appears to be a copy of the original alpha/ia64 unaligned.h header, so I converted it to use the new asm-generic/unaligned.h too PARISC: is just a copy of asm-sparc/unaligned.h, so I converted it over to use asm-generic/unaligned.h too PPC/PPC64: can do unaligned access directly in big-endian mode which is what the Linux kernel runs in S390: can do it directly as well SH/SH64: just has the memmove() code ala asm-sparc/unaligned.h, I converted it to use asm-generic/unaligned.h V850: has some clever code just like ARM, so I didn't touch it. So this is the patch I came up with. Signed-off-by: David S. Miller

[SPARC64]: Override {pgd,pmd}_addr_end() to handle vaddr hole.

2005-03-15T12:34:36Z

Signed-off-by: David S. Miller

[PATCH] remove obsolete linux/resource.h inclusion from asm-generic/siginfo.h

2005-03-13T08:46:25Z

Roland added this include with his 'waitid system call' patch, which was removed again after a while. Just the header inclusion was not removed. http://linux.bkbits.net:8080/linux-2.5/cset@4134b6dd1rY3qnaq7YABrXPXGvzzpw http://linux.bkbits.net:8080/linux-2.5/cset@41499f66EDHON_8B1FYGEzLZQ2u13Q Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ptwalk: pud and pmd folded

2005-03-13T08:21:15Z

Nick Piggin's patch to fold away most of the pud and pmd levels when not required. Adjusted to define minimal pud_addr_end (in the 4LEVEL_HACK case too) and pmd_addr_end. Responsible for half of the savings. Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds