[PATCH v5.10-v5.15] rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow

by: Paul E. McKenney Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Sasha Levin Signed-off-by: Vamsi Krishna Brahmajosyula --- kernel/rcu/tasks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 105fdc2bb004..bede3a4f1

Re: kernel

look at http://www.kernelnewbies.org also it has a section on books. you can also use IRC #kernelnewbies On 8/25/05, Shwetha V <[EMAIL PROTECTED]> wrote: > > Could anyone inform which will be a good guide to start learning the linux > kernel programming. > > -- > Shwetha V > Software Engineer

Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.

Hello All, Really thankful for your inputs! > Itanium instruction set is not as compact as some other architectures, > so the same program will typically require more bytes of code. I stopped the program on both amd64 machine and ia64 machine and grepped the values from /proc/<>/status and found

Multiple virtual address mapping for the same code on IA-64 linux kernel.

Hello All, Sorry to interrupt you. I have been investigating a problem in which there has been a dramatic core size (complete program size) of a program running on a IA-64 machine running kernel version 2.4.21-4.0.1 (A redhat advanced server distribution) compared to other 64-bit architectures l

Forcing kernel to avoid vDSO mapping.

Hello All, Sorry to interrupt you. There seem to be some architecture specific problems using ptrace in the vDSO segment on IA32, ptrace and read fails from this segment with BAD ADDRESS. I was just wondering if there could be any why we can tell kernel not to map this vDSO for optimization of s

Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?

Really appreciate that, is roland mcgrath listening? what's his email ID? On 7/23/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: > > On Fri, 22 Jul 2005, vamsi krishna wrote: > > > Hi, > > > >> It doesn't. The 32-bit machines never show

Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?

Hi, > It doesn't. The 32-bit machines never show 64 bit words in > /proc/NN/maps. They don't "know" how. > > b7fd6000-b7fd7000 rw-p b7fd6000 00:00 0 > b7ff5000-b7ff6000 rw-p b7ff5000 00:00 0 > bffe1000-bfff6000 rw-p bffe1000 00:00 0 [stack] > e000-f000 ---p 00:00 0

Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?

Hello, > > The location of the vsyscall page is different on 32 and 64 bit > machines. So 0xe000 is NOT the address you are looking for while > dealing with the 64 bit machine. Rather 0xff60 is the > correct location (on x86-64). > Both my process's are 32-bit process's, its just

Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?

Hello All, Sorry to interrupt you. I have been facing a wierd problem on same kernel version (2.6.5-7.97.smp) but running on different machines 32-bit and 64-bit (which can run 32-bit also). I found that every process running in this kernel version has a virtual address mapping in /proc//maps fi

Avoiding BIGMEM support programatically.

Hello All, I have a program working fine on a 2.6.xx-smp kernel, and the program crashes on the same version kernel with bigmem i.e (2.6.xxx-bigmem). I also found that for a same executable on bigmem kernel the virtual address's of '&_start' and '&_etext', seem to vary in every new run. Is there

Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.

Hello Alan, mm-hackers, I have been working this idea of increasing virtual address space of a process with the help of secondary memory. At first this may seem like the same virtual memory concept but its not the case. Imagine all the virtual address the compiler generates while creating the bin