mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: vkire@pixar.com (Kiril Vidimce), dmaas@dcine.com (Dan Maas),
	linux-kernel@vger.kernel.org (linux-kernel)
Subject: Re: kernel: ldt allocation failed
Date: Fri, 07 Dec 2001 10:12:33 +0000	[thread overview]
Message-ID: <5.1.0.14.2.20011207101157.00aeeda0@pop.cus.cam.ac.uk> (raw)
In-Reply-To: <5.1.0.14.2.20011207092244.049f6720@pop.cus.cam.ac.uk>
In-Reply-To: <E16CH6i-00059b-00@the-village.bc.nu> <Pine.LNX.4.21.0112070057480.20196-100000@tombigbee.pixar.com>

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/


  parent reply	other threads:[~2001-12-07 10:13 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.kit1f7v.j024op@ifi.uio.no>
2001-12-07  7:24 ` Dan Maas
2001-12-07  9:00   ` Kiril Vidimce
2001-12-07  9:15     ` Alan Cox
2001-12-07  9:13       ` Kiril Vidimce
2001-12-07  9:28         ` Alan Cox
2001-12-07  9:26       ` James Davies
2001-12-07  9:43         ` Alan Cox
2001-12-07 13:10           ` James Davies
2001-12-07 13:41             ` Dave Jones
2001-12-07 13:59               ` James Davies
2001-12-07 13:53             ` Alan Cox
2001-12-07  9:45     ` Anton Altaparmakov
2001-12-07 10:38       ` Alan Cox
2002-02-06 16:58       ` Denis Vlasenko
2002-02-06 13:42         ` Alan Cox
2002-02-06 17:20           ` Christoph Hellwig
2001-12-07 10:12     ` Anton Altaparmakov [this message]
     [not found] <Pine.LNX.4.21.0112070057480.20196-100000@tombigbee.pixar.com.suse.lists.linux.kernel>
     [not found] ` <5.1.0.14.2.20011207092244.049f6720@pop.cus.cam.ac.uk.suse.lists.linux.kernel>
     [not found]   ` <200202061258.g16CwGt31197@Port.imtp.ilyichevsk.odessa.ua.suse.lists.linux.kernel>
2002-02-06 13:19     ` Andi Kleen
2002-02-06 14:06       ` Dave Jones
2002-02-06 14:13       ` Alan Cox
2002-02-06 14:09         ` Andi Kleen
2002-02-06 14:39           ` Alan Cox
2002-02-06 16:37             ` bert hubert
2002-02-06 15:51         ` Bill Davidsen
2002-02-06 16:08           ` Alan Cox
2002-02-06 16:29             ` John Levon
2002-02-06 18:01               ` Alan Cox
2002-02-06 18:02       ` Denis Vlasenko
2002-02-06 15:12         ` Jakub Jelinek
2002-02-06 18:11           ` Maciej W. Rozycki
2002-02-06 20:19           ` H. Peter Anvin
2002-02-06 21:15             ` Jakub Jelinek
2002-02-06 21:17               ` H. Peter Anvin
2002-02-06 20:21           ` yodaiken
2002-02-06 21:00             ` H. Peter Anvin
2002-02-06 21:31               ` Jakub Jelinek
2002-02-06 22:05                 ` H. Peter Anvin
2002-02-06 22:20                   ` Jakub Jelinek
2002-02-06 23:35                     ` H. Peter Anvin
2002-02-07  0:21                 ` Alan Cox
2002-02-07  0:12                   ` Jakub Jelinek
2002-02-07  0:15                     ` H. Peter Anvin
2002-02-07  0:13                   ` H. Peter Anvin
2002-02-06 15:37         ` Alan Cox
2001-12-07  5:40 Kiril Vidimce
2001-12-07  5:58 ` Jeffrey H. Ingber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5.1.0.14.2.20011207101157.00aeeda0@pop.cus.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dmaas@dcine.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vkire@pixar.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®