Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
On Fri, 22 Jul 2005, linux-os (Dick Johnson) wrote: > Seems to be readable and starts with 'ELF'. It's something the the 'C' > runtime may library use to make syscalls to the kernel. Older libraries > used interrupt 0x80, newer ones may use this. Roland McGrath has made > patches to this segment so maybe he knows. This page is a vsyscall page. See http://lwn.net/Articles/30258/ -- JiKos. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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 [vdso]
> >> 32 bits
> >
> > hello john can you tell me what is [vdso], does it have any content
> > related file descriptor table it seems that the if I dont save this
> > segment during checkpointing, the file open descriptors (i.e FILE *)
> > seems to have null after restoration.
> >
> > Sincerely appreciate your inputs.
> >
> > Cheers!
> > Vamsi
> >
>
> #include
>
> int main()
> {
> long *foo = (long *)0xe000;
> printf("%08x\n", foo[0]);
> printf("%08x\n", foo[1]);
> printf("%08x\n", foo[2]);
> printf("%08x\n", foo[3]);
> printf("%08x\n", foo[4]);
> printf("%s\n", (char *)foo);
>
> }
>
> Seems to be readable and starts with 'ELF'. It's something
> the the 'C' runtime may library use to make syscalls to the
> kernel. Older libraries used interrupt 0x80, newer ones
> may use this. Roland McGrath has made patches to this
> segment so maybe he knows.
>
>
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
> Warning : 98.36% of all statistics are fiction.
> .
> I apologize for the following. I tried to kill it with the above dot :
>
>
> The information transmitted in this message is confidential and may be
> privileged. Any review, retransmission, dissemination, or other use of this
> information by persons or entities other than the intended recipient is
> prohibited. If you are not the intended recipient, please notify Analogic
> Corporation immediately - by replying to this message or by sending an email
> to [EMAIL PROTECTED] - and destroy all copies of this information, including
> any attachments, without reading or disclosing them.
>
> Thank you.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
On Fri, 22 Jul 2005, vamsi krishna wrote:
> 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 [vdso]
>> 32 bits
>
> hello john can you tell me what is [vdso], does it have any content
> related file descriptor table it seems that the if I dont save this
> segment during checkpointing, the file open descriptors (i.e FILE *)
> seems to have null after restoration.
>
> Sincerely appreciate your inputs.
>
> Cheers!
> Vamsi
>
#include
int main()
{
long *foo = (long *)0xe000;
printf("%08x\n", foo[0]);
printf("%08x\n", foo[1]);
printf("%08x\n", foo[2]);
printf("%08x\n", foo[3]);
printf("%08x\n", foo[4]);
printf("%s\n", (char *)foo);
}
Seems to be readable and starts with 'ELF'. It's something
the the 'C' runtime may library use to make syscalls to the
kernel. Older libraries used interrupt 0x80, newer ones
may use this. Roland McGrath has made patches to this
segment so maybe he knows.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [vdso] > 32 bits hello john can you tell me what is [vdso], does it have any content related file descriptor table it seems that the if I dont save this segment during checkpointing, the file open descriptors (i.e FILE *) seems to have null after restoration. Sincerely appreciate your inputs. Cheers! Vamsi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
On Fri, 22 Jul 2005, vamsi krishna wrote: > 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 one runs on 64-bit > machine and other runs on 32-bit machine. The write from address > 0xe to a file on a 32-bit machine fails, but does'nt fail on > 64-bit machine (the process is still 32-bit although it runs on > 64-bit). > > How can the virtual address of 0xff60 exist in a 32-bit > process ? (May be I have not made myself clear in explaining the > problem?? :-?) > > Best, > Vamsi. 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 [vdso] 32 bits Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Warning : 98.36% of all statistics are fiction. . I apologize for the following. I tried to kill it with the above dot : The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 one runs on 64-bit machine and other runs on 32-bit machine. The write from address 0xe to a file on a 32-bit machine fails, but does'nt fail on 64-bit machine (the process is still 32-bit although it runs on 64-bit). How can the virtual address of 0xff60 exist in a 32-bit process ? (May be I have not made myself clear in explaining the problem?? :-?) Best, Vamsi. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
To the best of my knowledge, It is the vsyscall page. The manner in which system calls were implemented has changed from using the 80h interrupt directly to using the vsyscall page (on the x86 arch). This makes for better throughput while running frequently used system calls which do not affect the kernel, but merely retrieve the information. A very good example is the system call to retrieve the current time, which is used extensively esp during logging. Google for vsyscall page and you will get more information. > on a 64-bit(uname --all == 'Linux host 2.6.5-7.97.smp #1 > x86_64 x86_64 x86_64 GNU/Linux) machine which is running the same > kernel, I try to write the contents of the virtual address on to file > with (r = write(fd,0xe000,4096) ). The write on this machine is > successful. But if I try to write the same segment on 32-bit machine > (uname --all == Linux host 2.6.5-7.97-smp #1 i686 i686 > i386 GNU/Linux). 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). Regards, Bhanu. On 7/22/05, vamsi krishna <[EMAIL PROTECTED]> wrote: > 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 file as follows > <--> > e000-000 ---p 00:00 0 > <--> > > You can find this vaddr mapping at end of maps file. > > on a 64-bit(uname --all == 'Linux host 2.6.5-7.97.smp #1 > x86_64 x86_64 x86_64 GNU/Linux) machine which is running the same > kernel, I try to write the contents of the virtual address on to file > with > (r = write(fd,0xe000,4096) ). The write on this machine is > successful. But if I try to write the same segment on 32-bit machine > (uname --all == Linux host 2.6.5-7.97-smp #1 i686 i686 > i386 GNU/Linux). > > The write on this 32-bit machine fails with EFAULT(14), but if memcpy > to a buffer from this virtual address seems to work fine i.e if I do > 'memcpy(buf1,0xe000,4096)' it write perfectly the contents of this > virtual address segment into the buf1. > > I had a hard time googling about this I could'nt find any information > on why this happens. May be some mm hackers may share some of their > thoughts. > > Really appreciate your inputs on this. > > Sincerely, > Vamsi kundeti > > PS: BTW I'am running suse distribution and will glibc will have any > effect on write behaviour ? (I though that since write is a syscall > the issue might be with the kernel the thus skipping the glibc > details) > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- The difference between Theory and Practice is more so in Practice than in Theory. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
>I found that every process running in this kernel version has a >virtual address mapping in /proc//maps file as follows ><--> >e000-000 ---p 00:00 0 ><--> If you run e.g. ldd /bin/ls, you get: linux-gate.so.1 => (0xe000) >on a 64-bit(uname --all == 'Linux host 2.6.5-7.97.smp #1 >x86_64 x86_64 x86_64 GNU/Linux) machine which is running the same kernel, I >try to write the contents of the virtual address on to file with (r = >write(fd,0xe000,4096) ). The write on this machine is successful. But >if I try to write the same segment on 32-bit machine (uname --all == Linux >host 2.6.5-7.97-smp #1 i686 i686 i386 GNU/Linux). > >The write on this 32-bit machine fails with EFAULT(14), but if memcpy >to a buffer from this virtual address seems to work fine i.e if I do >'memcpy(buf1,0xe000,4096)' it write perfectly the contents of this >virtual address segment into the buf1. Normally, you should not be able to read or write from/to there, since the permission bits are ---. >PS: BTW I'am running suse distribution and will glibc will have any >effect on write behaviour ? (I though that since write is a syscall >the issue might be with the kernel the thus skipping the glibc >details) If in doubt, start gdb and read the memory out using gdb (which will use ptrace). It should also give an error, if the permissions are enforced correctly. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 file as follows <--> e000-000 ---p 00:00 0 <--> You can find this vaddr mapping at end of maps file. on a 64-bit(uname --all == 'Linux host 2.6.5-7.97.smp #1 x86_64 x86_64 x86_64 GNU/Linux) machine which is running the same kernel, I try to write the contents of the virtual address on to file with (r = write(fd,0xe000,4096) ). The write on this machine is successful. But if I try to write the same segment on 32-bit machine (uname --all == Linux host 2.6.5-7.97-smp #1 i686 i686 i386 GNU/Linux). The write on this 32-bit machine fails with EFAULT(14), but if memcpy to a buffer from this virtual address seems to work fine i.e if I do 'memcpy(buf1,0xe000,4096)' it write perfectly the contents of this virtual address segment into the buf1. I had a hard time googling about this I could'nt find any information on why this happens. May be some mm hackers may share some of their thoughts. Really appreciate your inputs on this. Sincerely, Vamsi kundeti PS: BTW I'am running suse distribution and will glibc will have any effect on write behaviour ? (I though that since write is a syscall the issue might be with the kernel the thus skipping the glibc details) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
