On Wed, Feb 18, 2015 at 12:16 PM, Saumendra Dash wrote:
> On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:
> The syscall table is read only. You need to make it writable by changing the
> write protection bit in the Control Regs.
Wasn't that implemented from version 3 and not 2.6?
_
On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:
>> am on a VM running CentOS 6.6 with kernel version 2.6.32-504.
>Which probably has kernel relocation and ASLR enabled.
>> unsigned long *syscall_table = (unsigned long *)0x81600560;
>So that isn't pointing at the syscall table in t
We are doing prototype so much change have gone into kernel , we are
finding it difficult to upgrade to latest immediately
However I ran through the code once again, indeed kernel handles it
down_write(&mm->mmap_sem); in coredump_wait() makes sure the second
coredump is stopped and returns negative
On Tue, Feb 17, 2015 at 11:59 PM, wrote:
> On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:
>
>> am on a VM running CentOS 6.6 with kernel version 2.6.32-504.
>
> Which probably has kernel relocation and ASLR enabled.
>
>> unsigned long *syscall_table = (unsigned long *)0x81600560;
>
On Tue, Feb 17, 2015 at 11:57:05PM +0100, Ricardo Ribalda Delgado wrote:
> Hello:
>
> Since my first contribution I have used gmail as my mail provider.
>
> For sending patches I happily use git send-email and when I interact
> with a kverg list I use my gmail account via web (making sure that th
Hello:
Since my first contribution I have used gmail as my mail provider.
For sending patches I happily use git send-email and when I interact
with a kverg list I use my gmail account via web (making sure that the
mail is sent in text mode).
But when I am travelling and I need to reply to a list
On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:
> am on a VM running CentOS 6.6 with kernel version 2.6.32-504.
Which probably has kernel relocation and ASLR enabled.
> unsigned long *syscall_table = (unsigned long *)0x81600560;
So that isn't pointing at the syscall table in the r
When I execute insmod for the kernel module object file of the
following C code, the entire system hangs. The module replaces the
reference to original chroot system call with a new one in the
sys_call_table. The syscall_table address is correct as per
System.map(which returns 2 values for sys_call
On Tue, Feb 17, 2015 at 07:11:55PM +0530, Sudharsan Vijayaraghavan wrote:
> Hi All,
>
> We are running 3.8 kernel.
That's pretty old and obsolete, why are you stuck with that version?
> I have a unique scenario, where we hit on several issues in do_coredump.
> We have a SMP system with thousands
Hi All,
We are running 3.8 kernel.
I have a unique scenario, where we hit on several issues in do_coredump.
We have a SMP system with thousands of cores, one pthread is tied to
one core. The main process containing these pthreads runs in the first
core.
Here is the issue # 1
When one of threads c
Hi all,
What is the format of the kernel log buffer?
I am expecting something like this:
<>
<>
<
I am looking at an issue where kernel logs are getting corrupted. Knowing
the structure will help me.
Also, any other tips would be very helpful.
Regards,
Manty
_
11 matches
Mail list logo
