Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp883052pxt; Fri, 6 Aug 2021 16:54:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9eHxKvQmigN2S3BwR3/sE049Z6rdaQE4IG4dNXnRZRPIn6I/v1EANNkAxkdP3UQaYAaam X-Received: by 2002:a92:d346:: with SMTP id a6mr580410ilh.87.1628294042598; Fri, 06 Aug 2021 16:54:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628294042; cv=none; d=google.com; s=arc-20160816; b=1Ec2YKcqy03Uupo112svpXBOiFHKS2jrulYcgYdSs0DPJ/s1mml6bssF+TNo0zdEt4 UvzFOcgrppR05RhrQBoF55sG8POzJxx3W7WG3FgBqfoHRIc077jOQtCFtPAMPjcTPL7k Gfee28nS+oqqYiYdqGULHlXla+VRImxMvwOEEWu1aBecBm1IjwyGvWEmqjc7Cx1rfuq/ Uab4rwKpVNU46hmiCdD2tMrWp/YPj4kmalDSs0FiOYP59fN2Qu9OML0GWP2T8zchGQs+ vOTMKCGweh+clkBQ3SMbuGJTq70uFJMNVeFg58Oo0S6Vst3NrtBRkl73T1QwprIbpX9S xqRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :mime-version:user-agent:date:message-id:from:in-reply-to:subject :references:cc:to:dkim-signature; bh=+Yk7jS1kCh4T4Z0jmOABLJsPkhmyd3gwrABdX6XLTLk=; b=u2E2DaNQZuan3adXrU53kNdXr+dfKLlMwjo1PswJ4+xtQUiRyRJkTIRkhdycyMUZkK kIOAOAqL3FHjh7ghztq5IQw165c4w9svThycQ7+nyaabyWS+bgflM1yR9ZgET6wa2+Dg pSubJUa9kp/BstgfPLY6LxfJYB4MQyrXwkFr1NPT6HmNmUlZdA6zMFKlBq0hBAxOFkZf uE1oqyVwA5JT/PKbWnRa3G3vlXiLw+boxdmq0zXlfaKAUJPqUDrGI1vifpN+OFPxDyjX DLO57QityUUGw4mbeqqYkLMQIXcoXOd1jFezqa+R7D5HzGDwyzLSo4y4L/0pXh6XDqBT rJjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@uwaterloo.ca header.s=default header.b=640keLWx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=uwaterloo.ca Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e123si4706353iof.100.2021.08.06.16.53.51; Fri, 06 Aug 2021 16:54:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@uwaterloo.ca header.s=default header.b=640keLWx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=uwaterloo.ca Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237113AbhHFQwJ (ORCPT + 99 others); Fri, 6 Aug 2021 12:52:09 -0400 Received: from esa.hc503-62.ca.iphmx.com ([216.71.131.47]:48512 "EHLO esa.hc503-62.ca.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233896AbhHFQwJ (ORCPT ); Fri, 6 Aug 2021 12:52:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uwaterloo.ca; i=@uwaterloo.ca; q=dns/txt; s=default; t=1628268713; x=1659804713; h=to:cc:references:subject:in-reply-to:from:message-id: date:mime-version:content-transfer-encoding; bh=+Yk7jS1kCh4T4Z0jmOABLJsPkhmyd3gwrABdX6XLTLk=; b=640keLWxsk9jFlZbDaL71I1fjJL6NUdYe4xIBBc8Vi8vIKvSmbd20GF+ Z5VZ+vtacIviOjK+8/G0r0Yp/KG43+y25qhkturbY6v080AJJWEjaOIfx 1/4MeaJaTShT4dZI0dU9AeHCJaz30MWlT5EPmq/Zvv0ORmWzCCmrU3X+M Y=; Received: from connect.uwaterloo.ca (HELO connhm04.connect.uwaterloo.ca) ([129.97.208.43]) by ob1.hc503-62.ca.iphmx.com with ESMTP/TLS/AES256-GCM-SHA384; 06 Aug 2021 12:51:50 -0400 Received: from [10.42.0.123] (10.32.240.218) by connhm04.connect.uwaterloo.ca (172.16.137.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 6 Aug 2021 12:51:49 -0400 To: CC: , , , , , , , , , , , References: Subject: Re: [PATCH 3/4 v0.4] sched/umcg: add Documentation/userspace-api/umcg.rst In-Reply-To: From: Thierry Delisle Message-ID: <1dc64d75-da9b-272a-a9ab-7d2ae7a85764@uwaterloo.ca> Date: Fri, 6 Aug 2021 12:51:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.32.240.218] X-ClientProxiedBy: connhm03.connect.uwaterloo.ca (172.16.137.67) To connhm04.connect.uwaterloo.ca (172.16.137.68) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org  > All _umcg_ state changes here happen in the userspace before  > sys_umcg_wait() is called. So:  >  > W1: cmpxchg W1:RUNNING => W1:IDLE  >  - if OK, call sys_umcg_wait()  >  - if failed, do something else (notes below)  >  > W2: cmpxchg W1:IDLE => W1:RUNNING  >  - if OK, lock itself, set W2:next_tid to W1, call sys_umcg_wait()  > (will not block nor spin), restore next_tid and state/unlock upon  > syscall return  >  - if failed, do something else I am talking about the case where both cmpxchg() succeed and W2 sets *both* UMCG_WAIT_WAKE_ONLY and UMCG_WAIT_WF_CURRENT_CPU.  More specifically, if things are ordered like so: (ideally use monospace font)          - w1 -                     - w2 - w1:RUNNING => w1:IDLE|L   | S:IDLE => S:RUNNING       | sys_umcg_wait():          |      set ~UMCG_TF_LOCKED  |                           |   w1:IDLE => w1:RUNNING|L                           |   w2:RUNNING => w2:IDLE|L                           |   w2:next_tid := W1.tid                           |   w1:RUNNING|L => w1:RUNNING                           |   sys_umcg_wait():                           |       set ~UMCG_TF_LOCKED                           |       do_context_switch()      idle_loop()          | What does ttwu() do with w1 if it has not reached idle_loop yet? I am not familiar with the details of kernel context-switching, but in user-level threading, more specifically Cforall, this would be a problem. Between the call to do_context_switch() and and idle_loop(), there is a window where 2 CPUs run the same thread at the same time. One thread is performing the front side of the context switch and the other threads wakes up on the backside of the context switch. This behaviour invariably corrupts the program stack of that thread. Again, I do not know if that applies here. I am not exactly sure how the program stack is handled when inside a system call.