From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56232 invoked by alias); 27 Feb 2019 15:38:24 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 56220 invoked by uid 89); 27 Feb 2019 15:38:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=fear, madison, Madison, unusual X-HELO: mail-it1-f177.google.com Received: from mail-it1-f177.google.com (HELO mail-it1-f177.google.com) (209.85.166.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Feb 2019 15:38:22 +0000 Received: by mail-it1-f177.google.com with SMTP id e24so9840035itl.1 for ; Wed, 27 Feb 2019 07:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gnLlOAwuJ1beIDFQDR51/v/J3mjKEnTT6tXLAqOaZFI=; b=kPsjsKSBtn/r58hfE1IKZeaYXgz/qVlKkSQN1R+JpeaN+2gfzyYU8aGOeG3PALOdAE Wqg4Kev83R5I95ukzkEWYvMdI4DtdI6mbVGq61T3AdrmHwTA6rG4cNjin7VOK0Jo8x17 2E0Vfst1l1k8SumUZTwqV73tNp0arXoa9Utdn9Ry317Ht9yWlImpr0r3YZpEXfEWiXW+ sr7li6zh4n6Hg7rQjByke+Fdl2qOx58KQPcxVOqqoD9BnW421NnPyehn2p6zL2xaegHz K5qSX4FCBxtSkXR57irhZ6C9+v1HWnysFyyxOZxuUwMtAhKRg8bgPIWY9UkIeCBgdtJ5 HqBg== MIME-Version: 1.0 From: "E. Madison Bray" Date: Wed, 27 Feb 2019 15:51:00 -0000 Message-ID: Subject: Consider exposing mmap_is_attached_or_noreserve To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00481.txt.bz2 Hello, A very technical request regarding Cygwin internals: In mmap.c there is a function mmap_is_attached_or_noreserve(void *addr, size_t len) which is called from Cygwin's exception handler in the case of a STATUS_ACCESS_VIOLATION. This is called in case an access violation occurs in memory that was allocated with Cygwin's mmap() with the MAP_NORESERVE flag, and allows us to commit the relevant pages when they are accessed. After a successful call of mmap_is_attached_or_noreserve(), the Cygwin exception handler returns with ExceptionContinueExecution. Unfortunately, if the application happens to have a Vectored Continue Handler registered which happens to do something in the case of STATUS_ACCESS_VIOLATION (see [1]) there is no obvious way to tell if we're handling this sort of case. Normally this isn't too much of a problem: E.g. we could just check the address that caused the access violation and see if its status is now MEM_COMMIT (i.e. Cygwin ran its exception handler and all is good). However, due to the bug described in [1], if an exception occurs in code running on a sigaltstack, the Cygwin exception handler isn't run. This makes for a tricky to handle use case: What if some code in a signal handler function tries to access uncommitted memory in a MAP_NORESERVE mmap? It's probably an unusual, undesirable case, and I haven't personally encountered it *yet*, but I could imagine some cases where it might happen. In order to handle such a case it might be nice if mmap_is_attached_or_noreserve were able to be called by user code, perhaps as a new cygwin_internal(...) call. I'd happily provide a patch, but I fear this might be an X/Y problem that I'm not seeing. Thanks, Madison [1] https://cygwin.com/ml/cygwin/2018-05/msg00333.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple