Date: Wed, 26 Sep 2001 22:08:13 -0700 (PDT) From: Marcel Moolenaar <marcel@FreeBSD.org> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/30861: Linuxulator: stackgap does not handle recursion from interrupted syscalls. Message-ID: <200109270508.f8R58DG21377@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 30861 >Category: kern >Synopsis: Linuxulator: stackgap does not handle recursion from interrupted syscalls. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 26 22:10:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Marcel Moolenaar >Release: -current & -stable >Organization: FreeBSD >Environment: >Description: Peter says: Ever wonder why things crash for no apparent reason? I think I know why. Check out the stackgap_alloc() stuff. Then think about linuxthreads where multiple processes are using the same stack gap. Think what happens when one process does a translated syscall, blocks, and another one does a syscall and reuses the same gap space. :-( Solutions are ugly. :-( Possible solution 1: make the stackgap_*() functions reentrant and alloc/free the space. downside: we presently have a small gap space and dont "free" the gap space. We could run out of space easily. Possible solution 2: Use space below the user stack. We may have to do this. This is nasty too, because we will have to assume that there is nothing below the user stack %esp. Possible solution 3: Put a lock around stackgap functions so that translated syscalls are not reentrant. This is really nasty as it single threads linuxthreads syscalls. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109270508.f8R58DG21377>