From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2891EC433F5 for ; Sat, 27 Nov 2021 01:17:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3EE5C6B0075; Fri, 26 Nov 2021 20:16:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 39E316B0078; Fri, 26 Nov 2021 20:16:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 240506B007B; Fri, 26 Nov 2021 20:16:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 156106B0075 for ; Fri, 26 Nov 2021 20:16:57 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CCBBE1856301B for ; Sat, 27 Nov 2021 01:16:46 +0000 (UTC) X-FDA: 78852945612.31.FFC767E Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf28.hostedemail.com (Postfix) with ESMTP id 597AC90000A9 for ; Sat, 27 Nov 2021 01:16:46 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1637975804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DT9TnAjJN6p5cb67DY6dvVqAC4VHB/JbDn7hMhDJt80=; b=Q+8iBjG3F/zb99AbBGK+dFF02kU49RvpUvrTC9euWPcfCWynjkaNUWN0xY4JEuZJz62cCu VHHWgHLrGcDEkOZL3cypR9N+qqnO6H8ND9+VCgQ58PWX/tR10V4aqUHNQRdpEvfmdS/3aS 8ys2Aj+5ZJokVLrq4apn7E3sZNuZS76ca+YB0u58jzc/uiKSmMWEhPh6e//e7qQrK0KMr6 cQ+9MUNYvP6POJFTNWyeZFgtU/CHDF/u9qJtzE/8T8Vafgfu1e2PGez+ceUlQ8/EB91Rzf eqxt3+lJmVOz+A6FJmcvbYxYZfJ6axE3hphjk8tfcOit70bfYzqdAIXOfdOlGw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1637975804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DT9TnAjJN6p5cb67DY6dvVqAC4VHB/JbDn7hMhDJt80=; b=IZNHyB3f6u118NoaaChJJEbVl5AN4UTNZOgNIG1dYm6Tql1zO+WAlih9sJIUvZ4T8A53mc Dxlq5DTeyq5MNqBw== To: Peter Zijlstra , Peter Oskolkov Cc: Ingo Molnar , Andrew Morton , Dave Hansen , Andy Lutomirski , Linux Memory Management List , Linux Kernel Mailing List , linux-api@vger.kernel.org, Paul Turner , Ben Segall , Peter Oskolkov , Andrei Vagin , Jann Horn , Thierry Delisle Subject: Re: [PATCH v0.9.1 3/6] sched/umcg: implement UMCG syscalls In-Reply-To: References: <20211122211327.5931-1-posk@google.com> <20211122211327.5931-4-posk@google.com> <20211124200822.GF721624@worktop.programming.kicks-ass.net> Date: Sat, 27 Nov 2021 02:16:43 +0100 Message-ID: <87r1b2fldw.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 597AC90000A9 X-Stat-Signature: kyygx5fbce8giez7jhn8rsszaesm1apd Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=Q+8iBjG3; dkim=pass header.d=linutronix.de header.s=2020e header.b=IZNHyB3f; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf28.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-HE-Tag: 1637975806-841380 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Nov 26 2021 at 23:16, Peter Zijlstra wrote: > On Fri, Nov 26, 2021 at 06:09:10PM +0100, Peter Zijlstra wrote: >> >> - if (unlikely(ti_work & EXIT_TO_USER_MODE_WORK)) >> + if (unlikely(ti_work & (EXIT_TO_USER_MODE_WORK | _TIF_UMCG))) >> ti_work = exit_to_user_mode_loop(regs, ti_work); >> >> arch_exit_to_user_mode_prepare(regs, ti_work); > > Thomas, since you're looking at this. I'm not quite sure I got this > right. The intent is that when _TIF_UMCG is set (and it is never cleared > until the task unregisters) it is called at least once. Right. > The thinking is that if umcg_wait() gets interrupted, we'll drop out, > handle the signal and then resume the wait, which can obviously happen > any number of times. Right. > It's just that I'm never quite sure where signal crud happens; I'm > assuming handle_signal_work() simply mucks about with regs (sets sp and > ip etc.. to the signal stack) and drops out of kernel mode, and on > re-entry we do this whole merry cycle once again. But I never actually > dug that deep. Yes. It sets up the signal frame and once the loop is left because there are no more TIF flags to handle it drops back to user space into the signal handler. That returns to the kernel via sys_[rt_]sigreturn() which undoes the regs damage either by restoring the previous state or fiddling it to restart the syscall instead of dropping back to user space. So yes, this should work, but I hate the sticky nature of TIF_UMCG. I have no real good idea how to avoid that yet, but let me think about it some more. Thanks, tglx