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 D6FF9C63797 for ; Tue, 17 Jan 2023 08:34:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 508536B0071; Tue, 17 Jan 2023 03:34:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B8256B0073; Tue, 17 Jan 2023 03:34:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A6F56B0074; Tue, 17 Jan 2023 03:34:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2C0A76B0071 for ; Tue, 17 Jan 2023 03:34:16 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F20E4AAE67 for ; Tue, 17 Jan 2023 08:34:15 +0000 (UTC) X-FDA: 80363628870.14.60FA362 Received: from r3-23.sinamail.sina.com.cn (r3-23.sinamail.sina.com.cn [202.108.3.23]) by imf25.hostedemail.com (Postfix) with ESMTP id 2D878A000F for ; Tue, 17 Jan 2023 08:34:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf25.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.23 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673944454; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YceTkHuV/Nyl1AD8raUnVBwloUS6eSGFS9ax1ear/aI=; b=6P/GxH8f9Q86FztmEOWWZmtTff9vwexQ/Jwf2BsKVGZvVTBPnBK9H0AggP8ssL3RnKapS5 oLsohhnuGB+Rt37Z8OecHHLunoNxrXgQzq95hbxfcIJ2NVVGA5kVcHFDo0az7q4WcR79Ff +x6vQ132AHG5faMTjEPi828jLL+b0rg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf25.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.23 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673944454; a=rsa-sha256; cv=none; b=NMskFQBHib8CJr04Xmp1pCJAUFmWZw8sG39It5zoa2iy8MaPZYJcK6uOjhfPMd0h4KODv8 1NZrvGzibeAOhG+IW+q6Ff7FyxK3E+2lcVXc1mFYdNfucXjaZHc4BwfYPOEwNrHDeebcz7 EZ+UiYSDAazyqprvjxcLK/nWnGiGvBo= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.23) with ESMTP id 63C65CC10000C8B1; Tue, 17 Jan 2023 16:30:58 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 89138754920459 From: Hillf Danton To: Suren Baghdasaryan Cc: vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, peterz@infradead.org, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock Date: Tue, 17 Jan 2023 16:33:55 +0800 Message-Id: <20230117083355.2374-1-hdanton@sina.com> In-Reply-To: References: <20230109205336.3665937-42-surenb@google.com> <20230116140649.2012-1-hdanton@sina.com> <20230117031632.2321-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2D878A000F X-Stat-Signature: 5b4pumjstwyfig5gkitrbosheuehjji3 X-HE-Tag: 1673944451-985576 X-HE-Meta: U2FsdGVkX18fijyRwgVT1HligLVM1vSBwQVCxrI/FHx5W2H/1dEccLnUCMHeh9xbQF5fh7Mb2KQ7MO/S3PJ8VB/7NVGWyEytlU8r3iQT4aa1iAhucUjABD7fTObgxmXucd74iBxHvU0BsdQVlA0Rt467/3ko+XKx1VMCMKxAc2RY1ibyR6ESyJFQdkc8tnIwUSMLF//hK9oc5esPmYhCt47KzmRzXcm5NakfOT1KeNnx9Cb8gDJCG7TIYYWoNPq9MPhOUL/VpqCxoB/0aS6PsnF5rQdR6twrTQiG8ZlurKbBt72ZT90I4OGr/vmWclMwOlo78GwpBdnpD1S78wo60sPXYyk/ZMlgWLsWAxlfMRByc5aXksCRJ6v6Tpw2hjXP37MdXYbLnY4qTlsZYk3RtGdShP7XwpBA6AyzHC8kPpC9zJXDc0RE7i/brAOZngOcbzoabt9IZazgH79iu513up8m9UXqzhhaDs3JEuqt0Y2jIrekDuQwUglUy5BAKlfycXeb4Rp38s7OL6EOO2WFAefo1oglVbKmz1XgMM0rq4waNA2FwFV/rafnVO1udezAmZnrhvCGaUCqvL2zOgSjiYru5t5gZCTU86YZtXCkE3wSh4cNL9yYy5LJIEZdklKvR9MPj7sSJwivBg8zlpHteHpQQ9h0VrMXrvmjxDdScWoc5bZCFZEm7KZRSzpOr6J0IN5JLM6EsQ9bDOF10+5xDlmtes009Aj8aHTmIynohuvrATzY42owvP2yyikEcIgomvhLt0WNkcL1mTXw+qATKLg8ek2hT9OtTIWhH07EVn37aVIB/iG8f5A+OKp0z8OS5tcftQMWIr8B33RjI2Luxw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001571, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 16 Jan 2023 20:52:45 -0800 Suren Baghdasaryan > On Mon, Jan 16, 2023 at 7:16 PM Hillf Danton wrote: > > No you are not. > > I'm not wrong or the other way around? Please expand a bit. You are not wrong. > > > > If the writer lock owner is preempted by a reader while releasing lock, > > > > set count to zero > > <-- preempt > > wake up waiters > > > > then lock is owned by reader but with read waiters. > > > > That is buggy if write waiter starvation is allowed in this patchset. > > I don't quite understand your point here. Readers don't wait, so there > can't be "read waiters". Could you please expand with a race diagram > maybe? cpu3 cpu2 --- --- taskA bond to cpu3 down_write(&mm->mmap_lock); vma_write_lock L taskB fail to take L for read taskC fail to take mmap_lock for write taskD fail to take L for read vma_write_unlock_mm(mm); preempted by taskE taskE take L for read and read waiters of L, taskB and taskD, should be woken up up_write(&mm->mmap_lock);