> From: Philip Guenther
> Date: Wed, 4 Jan 2017 17:21:03 -0700
>
> On Tue, Jan 3, 2017 at 2:13 PM, Mark Kettenis wrote:
> > The diff below (partly by guenther@) removes ld.so's dependency on the
> > __got_{start,end} symbols by looking at PT_GNU_RELRO instead. On some
> > platforms (hppa and pe
On Tue, Jan 3, 2017 at 2:13 PM, Mark Kettenis wrote:
> The diff below (partly by guenther@) removes ld.so's dependency on the
> __got_{start,end} symbols by looking at PT_GNU_RELRO instead. On some
> platforms (hppa and perhaps a few others) this leads to even less
> writable pages. However, we'
The diff below (partly by guenther@) removes ld.so's dependency on the
__got_{start,end} symbols by looking at PT_GNU_RELRO instead. On some
platforms (hppa and perhaps a few others) this leads to even less
writable pages. However, we're not sure if this will work correctly
on landisk. So if som
On Sun, Jan 08, 2012 at 01:05:27PM +, Miod Vallat wrote:
> > Posix says that mmap(2)ing 0 bytes is bad and furthermore, our subsystem
> > is not written to support this (because there is no difference between
> > no allocation and a 0-byte allocation).
> > Strictly speaking, mmap(2) is to retur
> Hi,
>
> Posix says that mmap(2)ing 0 bytes is bad and furthermore, our subsystem
> is not written to support this (because there is no difference between
> no allocation and a 0-byte allocation).
> Strictly speaking, mmap(2) is to return EINVAL for 0 byte allocations
> and I intend to get that i
Hi,
Posix says that mmap(2)ing 0 bytes is bad and furthermore, our subsystem
is not written to support this (because there is no difference between
no allocation and a 0-byte allocation).
Strictly speaking, mmap(2) is to return EINVAL for 0 byte allocations
and I intend to get that into the kernel
