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 majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
-- "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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 07 2001 - 21:00:38 EST