On Fri, 28 Jan 2005, Rik van Riel wrote:
>
> The main thing I would really like to preserve is the
> space used for "near-NULL" pointer detection. That is,
> detection of trying to access a large index in a NULL
> pointer array, etc.
>
> I'd be happy to have some arbitrary value for the lower
> b
On Fri, 28 Jan 2005, Hugh Dickins wrote:
Perhaps you're coming from experience of various buggy apps
that get into difficulties if mmaps are found below mm->brk?
I'm not sure that we should be cutting others' address space to
make life easier for those, they should be ADDR_COMPAT_LAYOUT.
The main t
On Fri, Jan 28, 2005 at 02:14:36PM +, Hugh Dickins wrote:
> I had imagined that top down (non-FIXED) would continue to make
> more space available, the space below the text, just cutting off
> at PAGE_SIZE. There was a more serious lower limit on ARM under
> discussion before, but ARM doesn't
On Fri, 28 Jan 2005, Rik van Riel wrote:
> On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>
> > You seem to be on about something else, e.g. only forbidding the vma
> > allocator to return a vma starting at 0 when not specifically requested.
> > In that case vma->vm_start < mm->brk and similar
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
You seem to be on about something else, e.g. only forbidding the vma
allocator to return a vma starting at 0 when not specifically requested.
In that case vma->vm_start < mm->brk and similar are all fine.
Yes.
--
"Debugging is twice as hard as writi
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> The intention was to disallow vmas starting at 0 categorically. i.e. it
>> is very intentional to deny the MREMAP_FIXED to 0 case of mremap().
>> It was also the intention to deny the MAP_FIXED to 0 case of mmap(),
>> though I didn't actually swe
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
(b) sys_mremap() isn't covered.
On Thu, Jan 27, 2005 at 03:58:12PM -0500, Rik van Riel wrote:
AFAICS it is covered.
--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
+++ mm1
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
The intention was to disallow vmas starting at 0 categorically. i.e. it
is very intentional to deny the MREMAP_FIXED to 0 case of mremap().
It was also the intention to deny the MAP_FIXED to 0 case of mmap(),
though I didn't actually sweep that much
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> (b) sys_mremap() isn't covered.
On Thu, Jan 27, 2005 at 03:58:12PM -0500, Rik van Riel wrote:
> AFAICS it is covered.
> >--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
> >+++ mm1-2.6.11-rc2/mm/mremap.c 2005-01-27
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
(b) sys_mremap() isn't covered.
AFAICS it is covered.
--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
+++ mm1-2.6.11-rc2/mm/mremap.c 2005-01-27 12:34:34.0 -0800
@@ -297,6 +297,8 @@
if (flags & MREMAP_FIXE
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> The only claim above is the effect of clobbering virtual page 0 and
>> referring to this phenomenon by the macro. I was rather careful not to
>> claim a specific lower boundary to the address space.
On Thu, Jan 27, 2005 at 02:22:50PM -0500, Rik
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
The only claim above is the effect of clobbering virtual page 0 and
referring to this phenomenon by the macro. I was rather careful not to
claim a specific lower boundary to the address space.
OK, here is a patch that does compile against the curren
On Thu, Jan 27, 2005 at 04:52:54AM -0800, William Lee Irwin III wrote:
>> FIRST_USER_PGD_NR is a matter of killing the entire box dead where it
>> exists, not any kind of process' preference. Userspace should be
>> prevented from setting up vmas below FIRST_USER_PGD_NR.
On Thu, Jan 27, 2005 at 02:
William Lee Irwin III writes:
> William Lee Irwin III writes:
> >> There's a long discussion here, in which no one appears to have noticed
> >> that SHLIB_BASE does not exist in mainline. Is anyone else awake here?
>
> On Thu, Jan 27, 2005 at 10:29:12AM +0100, Mikael Pettersson wrote:
> > Ab
On Thu, Jan 27, 2005 at 04:52:54AM -0800, William Lee Irwin III wrote:
> On Thu, Jan 27, 2005 at 10:29:12AM +0100, Mikael Pettersson wrote:
> > About the only kernel-level enforcement I would feel comfortable with is
> > to have non-fixed mmap()s refuse to grab the _page_ at address 0. Any range
>
William Lee Irwin III writes:
>> There's a long discussion here, in which no one appears to have noticed
>> that SHLIB_BASE does not exist in mainline. Is anyone else awake here?
On Thu, Jan 27, 2005 at 10:29:12AM +0100, Mikael Pettersson wrote:
> About the only kernel-level enforcement I would fe
William Lee Irwin III writes:
> On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
> >> With some programs the 2.6 kernel can end up allocating memory
> >> at address zero, for a non-MAP_FIXED mmap call! This causes
> >> problems with some programs and is generally rude to do. This
On Wed, Jan 26, 2005 at 09:09:27PM -0800, William Lee Irwin III wrote:
>> There's a long discussion here, in which no one appears to have noticed
>> that SHLIB_BASE does not exist in mainline. Is anyone else awake here?
On Thu, Jan 27, 2005 at 12:18:56AM -0500, Dave Jones wrote:
> It's an exec-shi
On Wed, Jan 26, 2005 at 09:09:27PM -0800, William Lee Irwin III wrote:
> On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
> >> With some programs the 2.6 kernel can end up allocating memory
> >> at address zero, for a non-MAP_FIXED mmap call! This causes
> >> problems with some pr
On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
>> With some programs the 2.6 kernel can end up allocating memory
>> at address zero, for a non-MAP_FIXED mmap call! This causes
>> problems with some programs and is generally rude to do. This
>> simple patch fixes the problem in my te
On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
>
> >With some programs the 2.6 kernel can end up allocating memory
> >at address zero, for a non-MAP_FIXED mmap call! This causes
> >problems with some programs and is generally rude to do. This
On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
> With some programs the 2.6 kernel can end up allocating memory
> at address zero, for a non-MAP_FIXED mmap call! This causes
> problems with some programs and is generally rude to do. This
> simple patch fixes the problem in my tests.
linux-os wrote:
Does this mean that we can't mmap the screen regen buffer at
0x000b8000 anymore?
How do I look at the real-mode interrupt table starting at
offset 0? You know that the return value of mmap is to be
checked for MAP_FAILED, not for NULL, don't you?
Can't you still map those physical a
On Wed, 26 Jan 2005, linux-os wrote:
Wrong! A returned value of 0 is perfectly correct for mmap()
when mapping a fixed address. The attached code shows it working
The code that is patched is only run in case of a non-MAP_FIXED
mmap() call...
--
"Debugging is twice as
On Wed, Jan 26, 2005 at 01:20:53PM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Olivier Galibert wrote:
> >Given that the man page itself says that unless you're using MAP_FIXED
> >start is only a hint and you should use 0 if you don't care things can
> >get real annoying real fast. Imagine if yo
On Wed, 26 Jan 2005, Bryn Reeves wrote:
On Wed, 2005-01-26 at 17:34, Chris Friesen wrote:
linux-os wrote:
Does this mean that we can't mmap the screen regen buffer at
0x000b8000 anymore?
How do I look at the real-mode interrupt table starting at
offset 0? You know that the return value of mmap is t
On Wed, 26 Jan 2005, Rik van Riel wrote:
On Wed, 26 Jan 2005, linux-os wrote:
Wrong! A returned value of 0 is perfectly correct for mmap()
when mapping a fixed address. The attached code shows it working
The code that is patched is only run in case of a non-MAP_FIXED
m
On Wed, 26 Jan 2005, Olivier Galibert wrote:
On Wed, Jan 26, 2005 at 01:20:53PM -0500, linux-os wrote:
On Wed, 26 Jan 2005, Olivier Galibert wrote:
Given that the man page itself says that unless you're using MAP_FIXED
start is only a hint and you should use 0 if you don't care things can
get real
Bryn Reeves wrote:
RETURN VALUE
For calloc() and malloc(), the value returned is a pointer to the
allocated memory, which is suitably aligned for any kind of
variable, or NULL if the request fails.
This could get pretty confusing if NULL was a valid address...
Internally the library can us
linux-os wrote:
The seg-fault you get when you de-reference a pointer to NULL
is caused by the kernel. You are attempting to access memory
that has not been mapped into your address space. Once that
memory gets mmap()ed, you will no longer get a seg-fault.
Again, the seg-fault has nothing to do wit
On Wed, 2005-01-26 at 11:38 -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
>
> > With some programs the 2.6 kernel can end up allocating memory
> > at address zero, for a non-MAP_FIXED mmap call! This causes
> > problems with some programs and is generally rude to do. This
> >
On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
> >With some programs the 2.6 kernel can end up allocating memory
> >at address zero, for a non-MAP_FIXED mmap call! This causes
> >problems with some programs and is generally rude to do. This
> >
linux-os wrote:
On Wed, 26 Jan 2005, Rik van Riel wrote:
With some programs the 2.6 kernel can end up allocating memory
at address zero, for a non-MAP_FIXED mmap call! This causes
problems with some programs and is generally rude to do. This
simple patch fixes the problem in my tests.
Does this m
On Jan 26, 2005, at 11:38, linux-os wrote:
Does this mean that we can't mmap the screen regen buffer at
0x000b8000 anymore?
I believe the point of this is to ensure that *non*-MAP_FIXED
mmap calls won't use 0, IOW, it keeps things from accidentally
being mapped at 0 when the user didn't intend to,
On Wed, 26 Jan 2005, Andy Isaacson wrote:
Any particular thoughts as to how large a window should be reserved?
SHLIB_BASE is a bit more than 1MB, which is fairly small in the grand
scheme of things, but I guess I don't see why you'd reserve more than
PAGE_SIZE (or maybe PAGE_SIZE*2, though I can't
On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
>
> >With some programs the 2.6 kernel can end up allocating memory
> >at address zero, for a non-MAP_FIXED mmap call! This causes
> >problems with some programs and is generally rude to do. This
On Wed, 2005-01-26 at 17:34, Chris Friesen wrote:
> linux-os wrote:
>
> > Does this mean that we can't mmap the screen regen buffer at
> > 0x000b8000 anymore?
> >
> > How do I look at the real-mode interrupt table starting at
> > offset 0? You know that the return value of mmap is to be
> > chec
On Wed, 26 Jan 2005, Olivier Galibert wrote:
On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
On Wed, 26 Jan 2005, Rik van Riel wrote:
With some programs the 2.6 kernel can end up allocating memory
at address zero, for a non-MAP_FIXED mmap call! This causes
problems with some programs and
On Wed, 26 Jan 2005, Rik van Riel wrote:
With some programs the 2.6 kernel can end up allocating memory
at address zero, for a non-MAP_FIXED mmap call! This causes
problems with some programs and is generally rude to do. This
simple patch fixes the problem in my tests.
Does this mean that we can't
With some programs the 2.6 kernel can end up allocating memory
at address zero, for a non-MAP_FIXED mmap call! This causes
problems with some programs and is generally rude to do. This
simple patch fixes the problem in my tests.
Make sure that we don't allocate memory all the way down to zero,
so
40 matches
Mail list logo
