From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9542 Path: news.gmane.org!not-for-mail From: Linus Torvalds Newsgroups: gmane.linux.lib.musl.general,gmane.linux.kernel Subject: Re: Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Date: Wed, 9 Mar 2016 13:26:44 -0800 Message-ID: References: <06079088639eddd756e2092b735ce4a682081308.1457486598.git.luto@kernel.org> <20160309085631.GA3247@gmail.com> <20160309113449.GZ29662@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1457558826 29706 80.91.229.3 (9 Mar 2016 21:27:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2016 21:27:06 +0000 (UTC) Cc: Ingo Molnar , Andy Lutomirski , "the arch/x86 maintainers" , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra To: Andy Lutomirski Original-X-From: musl-return-9555-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 09 22:27:05 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1adldI-00060n-FA for gllmg-musl@m.gmane.org; Wed, 09 Mar 2016 22:27:04 +0100 Original-Received: (qmail 3176 invoked by uid 550); 9 Mar 2016 21:26:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3153 invoked from network); 9 Mar 2016 21:26:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=jOKmaUwDHPLXCnKgSlfBPPnooAh+VfSDOBHh6aqSfe8=; b=CIwOP/tkDtws9vml/BsyhYV83Sy6Nsqbda4QiRdmq7nrh5MjpqjF5UZEdnw9wwM9mf jhcqt4okKJejzKZ7xxXVYasmI8O0OOd11J7fLVRfapReRXllCwpS11EBYyuKBx3Vk/eV 41UYMhVxU0n89kUV30DU8oIx+re2uzMKwctz8OzGWXhi4vUbNPbwCVadLxx39GGLWKyx uhAmmtIQ55+r2h3SlU7gY8tZpAIaQCRjNO9Ye9gp20Lo0Pbm8xVQUSKtw6krzplkD5C6 UHiTy8ylODl83V5zfB4ZuE9YURqfRfFoMYrVYG+3iORqj6F3S0g3+XIf2s8R0OBkrIG6 TfXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=jOKmaUwDHPLXCnKgSlfBPPnooAh+VfSDOBHh6aqSfe8=; b=A9kcarO7a1DMF9Bb2mQ7weWPYWAXwdEmMgP9ZczXC4R9FfDOnxGjMIYBKHi3G6l1Kr L4euBGbs9BwvfGvNHLZ8/SejRe3RL3pd4T6xLOCQ1oXoX5B41YZnF1zhwHoZIELVH+76 DhagWZ/XDbYAvpDmmdoVfdWaIrT6eXdkin0gM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jOKmaUwDHPLXCnKgSlfBPPnooAh+VfSDOBHh6aqSfe8=; b=KohdCjURA6wAncGrf9AsQ8wdzcJNvG6i60scnmsuOuWgtOfI4VwogzP455pbXPhNWc MTCRGeS4FR6rnnlJng8Oxwc9hf4VqiGG1hqnyyaNb74FwCtsXEjOiefN78vwKrYuDeXf O6YjtDESjQHhgRF8tCUSXv2XsHDD2HVfrc30uHYFkfIaW2y5VVPuf8ly0Cm8hoH+LsiY 97ZOSqSoukrF2ulHsCdZooPXDI6TTuM8tpK8H06pHIeAB5IO203RLOFGMRaIdH9/9CW8 c/3Kf9v7q6jg1+mijlCy9TMNEagEdKzBL2yGbzv1a1ZjZJLUBatlpWSKxPdfibWlVDw1 yN8A== X-Gm-Message-State: AD7BkJKVCACqKODWwmdzdnKF5mC4rNffED+bfjQFV8bEziCSugwgzSzYQDF3Q/nlmXnVd0JRg76sm/Jkz+ApuQ== X-Received: by 10.50.79.234 with SMTP id m10mr477540igx.45.1457558805059; Wed, 09 Mar 2016 13:26:45 -0800 (PST) Original-Sender: linus971@gmail.com In-Reply-To: X-Google-Sender-Auth: i5K-9Ir5MCVBNCcDrh66tTe_GV4 Xref: news.gmane.org gmane.linux.lib.musl.general:9542 gmane.linux.kernel:2173422 Archived-At: On Wed, Mar 9, 2016 at 12:57 PM, Andy Lutomirski wrote: > > How safe would this be in a multithreaded process? For example, if > open() gets canceled in the "killable" sense, is it guaranteed that no > file descriptor will be allocated? Not all system calls can be killed, we only do the usual cases. A system call has to have the proper EINTR logic in place, so it's not like we kill system calls at any random point. > Let me try to summarize my understanding of the semantics. > > Thread A sends thread B a signal. Thread B wants to ignore the signal > and defer handling unless it's either in a particular syscall and > returns -EINTR or unless the thread is about to do the syscall. Note that for the kernel, we don't actually have to use a signal for this at all. Our existing "cancel system calls" code only works for fatal signals, but that's just a trivial implementation issue. We could add a system call that just sets a cancel flag in another thread, and we'd just use that cancel flag to say "abort the currently executing system call with EINTR" - in all the same places we currently dot hat "fatal_signal_pending()" thing. You'd still have to have all the user-space logic to do the cancellation cleanup etc. But now you could actually cancel a write() system call in the *middle*, which is currently just not an option. Linus