Re: kernel: ldt allocation failed

[Anton Altaparmakov]

At 09:45 07/12/01, Anton Altaparmakov wrote:
>At 09:15 07/12/01, Alan Cox wrote:
>> > I don't see how one can magically tell that this is an NVIDIA problem.
>>
>>We don't know. But since we don't have their source and they have our
>>source only they can tell you.
>
>Not doing any debugging is fine.
>
>However, looking at 2.4.16/arch/i386/kernel/process.c::copy_segments() 
>which generates this message it seems odd: It returns void, yet it can 
>fail because it is doing a vmalloc().
>
>When the vmalloc() fails, the new_mm->context.segments is set to NULL and 
>the function returns.
>
>That seems wrong, no? Shouldn't there be a panic() when the allocation 
>fails at least? Or even better the function should perhaps return an error 
>code?
>
>Considering there is only one caller (kernel/fork.c::copy_mm()) it would 
>be easy to modify copy_mm() to handle a returned error code gracefully and 
>goto fail_nomem, which would in turn result in kernel/fork.c::do_fork(), 
>the only caller of copy_mm(), cleaning up properly and returning an error code.
>
>Or have I missed something and the situation where the ldt is missing can 
>be recovered from? - I would think (without looking into this in the 
>kernel code) that loosing the local descriptor table would be rather 
>detrimental on the first context switch to the new process created by 
>fork... And considering all kinds of errors are being handled in this code 
>path, except for the vmalloc() failure, it seems like a good idea to add 
>the appropriate fail mechanism.
>
>If nvidia is causing this to get triggered they will likely run into 
>problems elsewhere anyway and we don't care but we should get the kernel 
>working. As it is AFAICS we have a potential DOS, just get the box close 
>to OOM and start calling man 2 fork and/or man 3 clone and you could trigger

s/man 3 clone/man 2 clone/

>  this with a finite probability.
>
>Best regards,
>
>         Anton
>
>
>--
>   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
>--
>Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
>Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
>ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [e-mail]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/