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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo