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

2005-07-22 Thread Jirka Kosina
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

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

2005-07-22 Thread Jirka Kosina
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

Re: Linux 2.6.x.x Execution Process Question

2005-07-09 Thread Jirka Kosina
On Fri, 8 Jul 2005, u u wrote: > Im looking for some help on some research I am conducting. Im trying to > understand the complete execution process from start to finish of an ELF > executable object on the i386 platform in particular, but x86_64 works > as well. So far I have come up with the

Re: Linux 2.6.x.x Execution Process Question

2005-07-09 Thread Jirka Kosina
On Fri, 8 Jul 2005, u u wrote: Im looking for some help on some research I am conducting. Im trying to understand the complete execution process from start to finish of an ELF executable object on the i386 platform in particular, but x86_64 works as well. So far I have come up with the

Re: Patch 4/6 randomize the stack pointer

2005-01-27 Thread Jirka Kosina
On Thu, 27 Jan 2005, John Richard Moser wrote: > Your patch 5/6 for mmap rand is also small. 1M is trivial, though I'd > imagine mmap() rand would pose a bit more confusion in some cases at > least, even for small ranges. > Still, this is a joke, like OpenBSD's stackgap. Also, besides security

Re: Patch 4/6 randomize the stack pointer

2005-01-27 Thread Jirka Kosina
On Thu, 27 Jan 2005, John Richard Moser wrote: Your patch 5/6 for mmap rand is also small. 1M is trivial, though I'd imagine mmap() rand would pose a bit more confusion in some cases at least, even for small ranges. Still, this is a joke, like OpenBSD's stackgap. Also, besides security

[PATCH] fix linking of ip_nat_tftp.o and ip_conntrack_tftp.o

2005-01-25 Thread Jirka Kosina
Hello, when both nat and connection tracking for TFTP protocol is turned on, the linking fails: net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of `ip_nat_tftp_hook' net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here The following patch fixes it, please

[PATCH] fix linking of ip_nat_tftp.o and ip_conntrack_tftp.o

2005-01-25 Thread Jirka Kosina
Hello, when both nat and connection tracking for TFTP protocol is turned on, the linking fails: net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of `ip_nat_tftp_hook' net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here The following patch fixes it, please

[PATCH] fix bad locking in drivers/base/driver.c

2005-01-24 Thread Jirka Kosina
Hi, there has been (for quite some time) a bug in function driver_unregister() - the lock/unlock sequence is protecting nothing and the actual bus_remove_driver() is called outside critical section. Please apply. --- linux-2.6.11-rc2/drivers/base/driver.c.old 2005-01-22 02:48:48.0

[PATCH] fix bad locking in drivers/base/driver.c

2005-01-24 Thread Jirka Kosina
Hi, there has been (for quite some time) a bug in function driver_unregister() - the lock/unlock sequence is protecting nothing and the actual bus_remove_driver() is called outside critical section. Please apply. --- linux-2.6.11-rc2/drivers/base/driver.c.old 2005-01-22 02:48:48.0