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 A59C5D1AD30 for ; Wed, 16 Oct 2024 08:53:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AB036B0082; Wed, 16 Oct 2024 04:53:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05B406B0083; Wed, 16 Oct 2024 04:53:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8B486B0088; Wed, 16 Oct 2024 04:53:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CA9556B0082 for ; Wed, 16 Oct 2024 04:53:56 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A9E9A121B8E for ; Wed, 16 Oct 2024 08:53:47 +0000 (UTC) X-FDA: 82678852788.14.A349440 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf13.hostedemail.com (Postfix) with ESMTP id EA4CF20003 for ; Wed, 16 Oct 2024 08:53:44 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=CA8xqmP3; spf=pass (imf13.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729068761; 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:dkim-signature; bh=Gir7xpD8ugj+DDX82DlQedD4jsgaIYC7WShYsyRR6aY=; b=czHCxITt3HE/Vn4J+3+0F0GTyTAml22dA5r8/AeVOo0balF3oyCsjIgkckZaDsJ1n06u2K P3QY6/ISi0+3dLdaxanILK+JYIvUbLUSRvm+PsqHBOjIJ13K9FZNUAG9At2DLzLtVzsNii S2KIN7xgcoINQkAkXSlLdIQK9JINwHM= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=CA8xqmP3; spf=pass (imf13.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729068761; a=rsa-sha256; cv=none; b=7toLfRYSo7RwIjzUabGcGck9/Vo8UpLNF74zw9myVaYNqmyxJW06UUkOVl5H1pxUBQ6J0M IfnLtmRlmC13WbLj/wFMWgWaS+j5wEUdOY4/HwbNZ7WU10st7AxwHB17te6yoexKXI8xWU 8muVijYtbvnzyQxDp6L2kd+2TUK1C4A= Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-20cb89a4e4cso29987465ad.3 for ; Wed, 16 Oct 2024 01:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1729068832; x=1729673632; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Gir7xpD8ugj+DDX82DlQedD4jsgaIYC7WShYsyRR6aY=; b=CA8xqmP3Awa4ny3x2Xi4rMdApfCZzpWEMa1vJ5EnJrVmHvQykK1dLleBl2ElCDXjhk G2w1n08vgvcEq06Z9JQp294mfh+vfa5z0biNjidOEIMEZ8jEILMGF+Ffsc4PFWPvRcVR jPt3nJjnKjx/tdrmnTAuoEd/JK0c17MXtDOSNYzh3QlPfp+KM9CFN0jNqTXzy1iQoBey l8LnmcBBN2pqyEKBiE4vKrHl06mpdPqVIFkGZLSIhpLbWh0fYzLrbfwdbNPWRL3qbXjQ yS+QiHeDKYsYrCgTN2E0bYuf08q3cFJU7iFWLd3gvtyQsOIlJFCY1MrOh/zVSPxY+s90 ANFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729068832; x=1729673632; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Gir7xpD8ugj+DDX82DlQedD4jsgaIYC7WShYsyRR6aY=; b=cjo/7uvnZjmYpGODVro6wykC/vP5GDSF0D+bnyX8XLlQpuCna4SZUSlt9xNfeb6Zmi w4W6RcbYov4gHpEdOC97nOOQ6f08hLh2EvATWixF53Vy7apBKd8eN1z8eKecwPe6CtWn KQj1MC+o1hs/xtu6adQO5QOT2fGdJR9SH0/wRyQkbiL0NobdwTc1AN0oU4KZxhqV2H/f fvVMxD8e3Bt3QiAoHHMTtWjFsPnpX6jmigGjE319Esg1KaKj6ghPwsEeOi6UlkTaLauX bs0Esuitn/PpT1v4ouxFFO5p+s3fz7kq+2ZoMKTlELj+jQtDSsRoQUDu5TEp1KJJRU5n bEMg== X-Forwarded-Encrypted: i=1; AJvYcCWEuQ/xChgcotdFM5vTKDtGS3UINiL/gmhdGBPxRWPFaozErvI1WlZ3gLDmtcAeIJvNG/hZVrTtQQ==@kvack.org X-Gm-Message-State: AOJu0YxBEMwusN5ySEZK/j2Bl+OQ7Yf5MdfUY9GdXc9ukpe/k0k9uK9V wWkjqhlYdeGqZvow7tJBqxehnzoASJW6nA911Am9OXT1/McKkQM9h5tom2GiuVw= X-Google-Smtp-Source: AGHT+IEVMm7X0AVlDzVsyiRLmaVcCoisbwqSGsrNjL5NMGRC6KolcJe58ILg76KsUXeoN8sgY5EwKw== X-Received: by 2002:a17:903:40c6:b0:20b:5351:f69a with SMTP id d9443c01a7336-20d27f3fae7mr43412215ad.58.1729068832048; Wed, 16 Oct 2024 01:53:52 -0700 (PDT) Received: from GQ6QX3JCW2.bytedance.net ([203.208.189.6]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20d17f84e66sm24692955ad.18.2024.10.16.01.53.48 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 16 Oct 2024 01:53:51 -0700 (PDT) From: lizhe.67@bytedance.com To: peterz@infradead.org Cc: akpm@linux-foundation.org, boqun.feng@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lizhe.67@bytedance.com, longman@redhat.com, mingo@redhat.com, will@kernel.org Subject: Re: [RFC 0/2] rwsem: introduce upgrade_read interface Date: Wed, 16 Oct 2024 16:53:45 +0800 Message-ID: <20241016085345.46956-1-lizhe.67@bytedance.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241016080955.GR16066@noisy.programming.kicks-ass.net> References: <20241016080955.GR16066@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: EA4CF20003 X-Stat-Signature: fwxqh9hqr7ox4dk5i7366qzcaeesbspc X-HE-Tag: 1729068824-165419 X-HE-Meta: U2FsdGVkX1/RwNB9+u8lfNeH+hE3bDYlSZ9HkeMoLrR2Ol7yirbUAkVEKZZBl6uSyjZRij4YZAErENccHIDva0zDeCu++AJS0LArbGYKEx6HoBphSSd/qzv5fJv3NEEEWEqKa1wX07fhr9dWieQuiw/WrLQ0koKCDOecdapEEYFrjcAApddltEKQxLbxN+2MYfIsFVOFbtoMJIk+FPRAtN80IYtSCsW2h56gUws0c9wiqWAYDBCdqaik+jDPhajePj5J0A0Sl95/fE+DgkXtldaVFKoWEaVEYNUwvgVDfUwb3C78HvYiXlqgP0JykzNwJ9oLBGI1ck8s80ZKXVT0NE3z22pVWZOn5yw/J73nIlAXHNUBJEWI80hCLE7IzQpLPPex5vmY1CIoW5KvPwMmX7jsPx6+6kOJjcOPwXwaQszVN04SKwKxP6lLsT+ZITTjgcinEn/ue+5kKpZDO+31lgqrXNwWysxRndS7Y9tCTE9TSlRhSuHbCniM2HVxY0Cc1grlrhgDayuPnjpWrWWLpqoB7kFvtIC+hkd5nUx6F1Xizs2PjbVFOS7wDlBBcQ8eBizdjtJeosjNa0grMnHqgrZDKZrMGwA4I576zMoF/ytY9303LLxVK84j5eEeYka19BfhqunyvmUYgllHQWVJpzoid8TelGKM8OABJpM/GQmZTAzJU/VSZm7HI2W/aZ9fbG9T+78KmgzaQUyP9EUNFVq7lt5ttSQATyz+eUx3n0KXa4TZvRv6uR54BxXIlxv3YIAdwuFLyo7PM3j59GyA6EzyZqh9kZizwT5H8g2JvMsDU6OYhVTow0eCu0t28XvgKuJC7k1aOulOM627YffWMZyvVMC8IIG8B2qpgsr8d6ofTz8Y6pbwOmA9AgRj8zB6+C7Y3rtMaB7qjRwBl25uzq7GiI2Jv3m+Axwt+yWReF9w+nhJ9IKw88s/wA/6eixVO61y/4j91OdQFb79wkL oeL8hDcT ky5CdbRR4qkiHiWoCrfbVP3rlkKTFOMepBmC11hRGMwO45blIAX7zH2ny/8s+Lj3iAx26+6rCVo5ZVf9BfyBzjI6VXKVjCX3t+sDk9BMNhSjWO20MlKRPRSUTEKL7dbAXPVxCgcRPguisS65KBfuGaD7Ajh/pGSLpLwFnwJNN2xil3vkwFFAGDNB3OXHzm+1tzTFBe7IrnWARexxacKirUX0sDozjl7OLP/ETdZ2PUxRwNnP0Pg7U+U+29DQ0wngvmpIeIp3cuMuzjKxCCoyv9Vmb5U/wuj3hBzcN4/O4M27Xa6/EcrDulBhtttwCL3bCQ3IGW0PgrSrdUNyUgGLHSB235+fs0asZdN7ghQ5DuQofMG9orhMKmli2XKWeoPteTKFTrt7rR6D75SuxtuhABJxO48SrXQGU07NrTVkjwJeEGpf/6wrbadUbKBjapCRbpiCoY2NKy3shb90yn0Xeu1wnfw5YYbfHqekyBtap4qGPMEs= 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: List-Subscribe: List-Unsubscribe: On Wed, 16 Oct 2024 10:09:55 +0200, peterz@infradead.org wrote: > On Wed, Oct 16, 2024 at 12:35:58PM +0800, lizhe.67@bytedance.com wrote: > > From: Li Zhe > > > > In the current kernel rwsem implementation, there is an interface to > > downgrade write lock to read lock, but there is no interface to upgrade > > a read lock to write lock. This means that in order to acquire write > > lock while holding read lock, we have to release the read lock first and > > then acquire the write lock, which will introduce some troubles in > > concurrent programming. This patch set provides the 'upgrade_read' interface > > to solve this problem. This interface can change a read lock to a write > > lock. > > upgrade-read is fundamentally prone to deadlocks. Imagine two concurrent > invocations, each waiting for all readers to go away before proceeding > to upgrade to a writer. > > Any solution to fixing that will end up being semantically similar to > dropping the read lock and acquiring a write lock -- there will not be a > single continuous critical section. According to the implementation of this patch, one of the invocation will get '-EBUSY' in this case. If -EBUSY is obtained and the invocation thread continues to retry instead of dropping the read lock and acquiring a write lock, it may cause problems. Of course, this patchset only try it's best to achieve a single continuous critical section as much as possible, and there is no guarantee. > As such, this interface makes no sense. This interface is just trying to reduce the overhead caused by the additional checks, which is caused by non-continuous critical sections, as much as possible. Rather than eliminating it in all scenarios. So would it be better to change the error code to something else? So that the caller will not retry this interface?