On Tue, 4 Apr 2000, Jesse Pollard wrote:
> > [...]
> > > > If there's no enough memory to *run* the process, it will fail.
> > > > Why should the system consider the worst (uncommon) case and allocate
> > > > the whole address space?
> > >
> > > It doesn't fail. the system killed itself.
> > >
> > > Irrelevent - malloc is the defined API, and the API is defined to return
> > > null on allocation
> > > failure. It doesn't do that in a consistant manner.
> >
> > brk() is the defined Linux API. Malloc() means nothing if you're not
> > using C.
>
> I can call malloc (the binary) from assembler if I feel like it. It isn't
> C dependant. Fortran I/O uses the same allocation when it uses the runtime
> library that opens files. malloc is used. It is the defined API. malloc
> uses brk. Now just what are you smoking...
Yes you can call malloc() from assembler. But it's not the 'defined' API.
The kernel does not care if the system call is in a library function
or in your program. The kernel sees only a process, which is performing
a system call. The system call itself is the defined API. Not malloc.
[...]
> > Already seen. Nothing do to with overcommit.
>
> You really are blind.
A nonsense argument. Answer diverted to /dev/null.
> > If you run your system in constant OOM conditions, you should either:
> > 1) use Rik's patch;
> > 2) avoid that anyway;
>
> It just shows that you don't understand resources.
A nonsense argument. Answer diverted to /dev/null.
> > The process asks the kernel to extend its address space with brk().
> > The kernel does what the process asks.
> > The process does not ask to allocate memory.
> > The kernel does not allocate memory.
> > So simple. It's the defined brk() behaviour. And AFAIK, doesn't break
> > POSIX.
>
> It does because malloc (the defined API) uses brk.
^^^^^^^^^^^^^^^
It is not.
> > > A correctly functioning POSIX compliant program should work the same on
> > > Linux as it
> > > does on Solaris/Irix/UNICOS... Unfortunately they don't. Nothing wrong
> > > with the program.
> >
> > Of course the program is wrong. It's using some non-POSIX implementation
> > details of Solaris/Irix/UNICOS. It's implementation dependant. And NOT
> > POSIX. So why should it not fail under Linux?
>
> No it isn't. It matches all posix requirements. (after all it could be the
> validation test for posix compliency... These other systems have passed, Linux
> doesn't.)
Plain FUD. Answer diverted to /dev/null.
[...]
> > > > Never said that.
> > >
> > > Sure you did. "malloc doesn't allocate memory..."
> >
> > "users really don't care if malloc returns a bogus pointer" - I have
> > never said that.
> >
> > "malloc doesn't allocate memory..." - I've said: "brk() doesn't allocate
> > memory...".
>
> malloc can't allocate memory unless brk gives it.
>
> Besides (and I give the full quote, apoligies for paraphrasing):
> Date: Mon, 20 Mar 2000 19:16:26 +0100 (CET)
> From: Marco Colombo <marco@esi.it>
> To: Jesse Pollard <pollard@cats-chateau.net>
> Cc: linux kernel <linux-kernel@vger.rutgers.edu>
> Subject: Re: Some questions about linux kernel.
>
> On Sun, 19 Mar 2000, Jesse Pollard wrote:
>
> [...]
> > NOPE - if the process requests it and is granted it, then it should have
> > access to it. It is not up to the system to say "here it is, but don't use
> > that part of it, because I really didn't give it".
>
> malloc() does grant you what you (the process) asked for: it extends your
> valid address space. It does not grant you any bit of RAM (page-frames
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> will be allocated when you access them, if available, or the process will be
> put to sleep) or swap space (with overcommitting, it will be allocated when
> the pages are paged-out). If you want the kernel to *grant* something,
> you'll have to ask for it. You want RAM, not just VM, use mlock(). You don't
> need RAM, but you need safe backing store, just create a file, fill it, and
> mmap() it. If applications die because they treat malloc() as mlock(), it's
> programmer's fault, not a kernel issue. malloc() it's just an interface to
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> brk(): it does not "allocate" anything (despite of the name) (kernel Gurus:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> maybe it allocates PTEs and other kernel resources, ok...).
> So when you access that part of your address space, you should be prepared
> in doing I/O instead of memory access (most applications are unaware of it,
> just because they need not to know... but applications depending on
> performances, such as benchmarks, WILL notice it), or even expect a failure.
>
> Therefore you are saying that the pointer is not usable... and are arguing
> that users don't care if malloc returns a bogus pointer.
> -------------------------------------------------------------------------
An address, being just a name for something, is always 'usable'.
An invalid address is one you compute yourself in a (buggy) piece od code.
That's what i'd call a 'bogus' pointer. Buy if you write a buggy C program
you don't need an OS to tell you it's buggy.
If you write a valid C program, none of your pointers will be 'bogus'.
Yes, if you use it, you may be killed.
char a[10];
a[1] = '\0'; <- the process is executing this C program statement...
- the user types '^c', the process gets SIGINT.
- the user types '^z', the process gets SIGTSTP.
- the user types '^\', the process gets SIGQUIT.
- the sysop types 'shutdown -h now', the process gets SIGTERM (and SIGKILL).
- the modem drops the connection, the process gets SIGHUP.
- someone cuts the power chord, the process gets SIGPWR (supposing the HW
and the OS support that);
- the uses types 'kill -USR1 <pid>', the process gets SIGUSR1;
- the systems goes OOM, the process gets SIGSEGV (or SIGKILL).
Of course the pointer (which was not obtained with malloc(), BTW)
is NOT bogus. But your process got the signal anyway.
I don't see any difference: an external event occurs and the OS reacts
killing (signalling) a process. Your process was accessing a valid
address in all cases. Tell my why the last case sounds (to you) so
different from the others.
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
>
> Any opinions expressed are solely my own.
>
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:11 EST