(Urrgh. Have to be more careful about accounts ... that on's supposed to
be long gone.)
> firstname.lastname@example.org (Michael L. Galbraith) wrote on 10.01.98 in
> > On 9 Jan 1998, Kai Henningsen wrote:
> > > Did that. It needed one minow tweak: change all #define kfree(...)
> > > xx(...) into #define kfree xx, otherwise the NCR 7/8xx driver won't
> > > compile (it takes the address of kfree).
> > >
> > If I were you, I'd write a local kfree func so I didn't have to fiddle
> > with the kfree wrapping. Also, casting kfree to void kfree(void *, int)
> > isn't ok.. is it?
> I'll have a look at that.
Made it so. Don't think it makes a difference.
> > > However, I can look at the results 'til my eyes fall out and still not
> > > see the problem.
> > >
> > > Attached are outputs from free, ps -lax, and dosum, from a time where
> > > the system seems to already have lost significant memory.
> > I looked at the output, and it appears that someone is vmallocing like
> > *mad*. You could try wrapping vmalloc to see who's doing that.
> Will look at that, too.
I made a very crude patch which, with some obscene command line for
searching /var/log/messages, made me find it, I think.
It's in process.c, line 484. It's when dosemu forks Linux programs. (This
is in copy_thread, but only if the thread has an ldt.)
* I can't tell in which kernel versions this bug exists. I've only
recently changed the DOS program in question (a mail filter, which now
uses Linux PGP instead of DOS PGP, and thus calls a Linux program very
often - but only while filtering.)
* It's quite obvious why nobody noticed this before. I doubt very many
people do something like this.
I'll have another look to see if I can find what's wrong, but I suspect
other people will be faster at that.