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 EB1AEC04FDF for ; Mon, 14 Aug 2023 08:21:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D1988E0002; Mon, 14 Aug 2023 04:21:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6818A8E0001; Mon, 14 Aug 2023 04:21:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 570E88E0002; Mon, 14 Aug 2023 04:21:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4529F8E0001 for ; Mon, 14 Aug 2023 04:21:25 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D3E561C98BD for ; Mon, 14 Aug 2023 08:21:24 +0000 (UTC) X-FDA: 81122015688.24.4C23C85 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf27.hostedemail.com (Postfix) with ESMTP id 1D77B40013 for ; Mon, 14 Aug 2023 08:21:22 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=bgRWTGED; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692001283; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EfzDg0tcvsZaIz86c4Cz2T/dWCigh2lZ1yHtRanABY8=; b=tpdKBLbJgqx5g03n3QmhuwPkG1OTzcTIL1RWHmxjZ/fczE5umrHRNlfQ/3RGzR/wM0pPgy zxYCsOYDl3gP0LacUvlBTyuWubCHjtMfItyOqEax6583XfgQ40MR7Rk9V1XEMRl91P/TPQ WLv1vZt6n3nADePM2RNs8O9U8SxXswE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=bgRWTGED; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692001283; a=rsa-sha256; cv=none; b=dMbT9iKOkvEobnZwUeugSeTTQV6AtVdYiDlts1lo03aa7p2/GxU4ANi1k/iAF+fwUMj6Ah DK0zL7/dmNtaBPZit3RUIsFHdu+ccf2q8sdi4Yy8C7qUtAFpOuEA6ISHMXgui2p6udGhzD cAb/sX7QVAj8mtPnG+h3ZQjfzezLSvA= Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3a5a7e7cd61so2533005b6e.0 for ; Mon, 14 Aug 2023 01:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692001282; x=1692606082; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EfzDg0tcvsZaIz86c4Cz2T/dWCigh2lZ1yHtRanABY8=; b=bgRWTGEDX+DBUNiCRpyOaEjR3cpZfC915z0NyfMFtHVeKu+a8iHB9jY03vMaBMT8wk DphqS3FFL4hG48q9b+ERoGVKnvZz1P9sU5Wgqc9vJTcI0MEaRxHX1po/OCA/BY6kTtpn /ADaYDwv2yLGHonokL4ivI4T1CKdoDYVbr4sc/OSTSW5rvaQWpyr8c9dewPDYHVOKJUO r3xtz6kzEIj4YUdmcR2LxhTIEjmP7e83zVgNCyjaLhUSjZDtjvcGQjig+oH/TvNIpW+k ykZZUQDyaryszGSnd19kyK+JwUvZhGxh5TaaUSGcy+wosP7wH+QD9SEe7tJHNqMvRZze 15/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692001282; x=1692606082; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EfzDg0tcvsZaIz86c4Cz2T/dWCigh2lZ1yHtRanABY8=; b=EnM0fvbxDv8vLCMdpVsh08yCp0uZWCeh4gcMKRcihcwUVr6YPv3gKPjfSr77Ry4RFk TKbGY598h3tGDsKHxacCbdExa1Cot0JCE+ptAmJpifb3YPFIbFz7gg1Jw1WGx2J0gxVf v25s39o34j38kCj87NGYizcbQYfH0BiZ6nmUo9+rJcVxSunDqTcxLeXhUfgB6O5SfZBp Gne2hvQbAexl8SIa/pgGFNujCstAtugqkCd6cHlqtSBTITuxhrBRSFEk86BzzEQ6jgrQ N5vRP+uJA6DOBWGzCfSiMmTXcG1eL8wxAmuLmRmquFfsHDo2vHxHD8OXoQY6w+WwPqKH YBlQ== X-Gm-Message-State: AOJu0Yyqd6lbXEHsTN2JvHeZ2gSp4nLgSzHYO803+C1r8c8e2gbxaXiW TTnW3rj1N5Awm9idekl0M71paI7a/VbT99xrD2A= X-Google-Smtp-Source: AGHT+IFr3MOzKwuHkNHECq4eLP71wzXUVrb9SjmwKDzpW8JnlO6/A0HXTjLcdBREw41rM+vs58pbN0Ye/jRkXMLo+YM= X-Received: by 2002:a05:6808:1508:b0:3a1:bced:9e83 with SMTP id u8-20020a056808150800b003a1bced9e83mr8385042oiw.5.1692001282099; Mon, 14 Aug 2023 01:21:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:9cf:0:b0:4f0:1250:dd51 with HTTP; Mon, 14 Aug 2023 01:21:21 -0700 (PDT) In-Reply-To: <00dd353b-e5aa-69fb-6b52-cb59028ea90a@redhat.com> References: <20230813123333.1705833-1-mjguzik@gmail.com> <00dd353b-e5aa-69fb-6b52-cb59028ea90a@redhat.com> From: Mateusz Guzik Date: Mon, 14 Aug 2023 10:21:21 +0200 Message-ID: Subject: Re: [PATCH] kernel/fork: stop playing lockless games for exe_file replacement To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, brauner@kernel.org, ebiederm@xmission.com, akpm@linux-foundation.org, linux-mm@kvack.org, koct9i@gmail.com, oleg@redhat.com, dave@stgolabs.net Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Stat-Signature: unrqh6wnjck5n86t4nyix98gsdi14xoj X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1D77B40013 X-HE-Tag: 1692001282-623844 X-HE-Meta: U2FsdGVkX18EKe3fqnRb905M8vj9m2lG2Lim6u88uIMXFO2jFpKCI2yXulExGkmzSxiYa3HCV0wg78RMh37Xm90G8fwNOubYiZRqtSq3tgMgzFS/hMpAfQzdHK3ktAWzSqg1DXgCwPTDYEvXqQXlO3IS650q4g3WbbQE00T+yG5i/IHnqOjG3hBVfp+XDBZSjrQFdWTwEzGP79vnl3Qu2Xe1+PyWut3S86TuNpAwyBzv8jplJaixmbQ9yDPZJ0XFW58aGMvnQ74gqU2f1t/8m0LCPv/VI6mnF2pzdD9z2Y+Nviq3mO1zTJcF+WeevfI4vkOdpmpjdJ0JrkqybECrLsAu7wxVgk6a9lDvrDskUMrEiXgyiUhiMcnQr/z4ZNtsiOGwlI3mckO5aL7HShIGAg9DLzD8VNrJQe9UT6P7yhKI0576QvT1i+XrUUPH2CmcAmt98Rw6b9rV0m4A4t8TioxLiZyC0GmjCO+OCn2XbNXNXvTvdgDfAh3ktRGQwhHgtOjoR4Ssty9pLBatFVGd4IHQd3Wkkd+dQfzM4gReLfOA6ieQyTRC+CqV6PCJyGv8fbSLzQaxoAixMvzIcoOnrazpGESGjABhOg5KiX6kmoo0IgTbSizX+kotfAr3r/T/jfCiyCZWhP7eI/bxPR5sJFUhhmKmMhWMCE14XjLPb8idJ9GjBfG8xSrtsz2ODjJEK4a2a2IyDYum/f5dcbWrmU51w1J1G3SdSasOudE1BGA3Y9AIRczZ9mXaq9VBeZcwHJuybE7TPC89X3xnTRjX+hWu7dahoxezX8VE8S5Dus32pl+raoEMeheVFbbqVPKrhFg5HcVwsm7qc3fmZWPX1AdvzJxGViPkoE3Mg06x4eQAafJHIJCfPN7WbtKWk9FSHBdRT8XJqMiJ1gWJB7hMVHN8rpjUyfy5adlDxDaqy6ZswcwWe+wsEmvu+NDVU/BCpIHZQtqVi7MGtPJY3lP 5/mT+pEY JAeNfjWW5abTDcCKxyeK+j1N8F0P8dp11sG3tyougzO7OiZOU79ajhum1v106swrIILZwv4FzQ7/f4XkW6nnnb8RfcxmWScbeP9thLpAUtK/EIxOvMZl29iNxCiVhOm/uSVViYtmrmrH+WRW/cVVV0tYBuwhSbxNDXsq/wydMDPsvQvLh/8Kzny70rDKMTB7UHb8m3SALWB9ffgk+YIcBKHxRhQNcY0fyX6NBpIFjDjtOhxpxySlspEVwOdK3pixpMecoBiupvxzWVL3QBRTbCGWp2yeE0m4PNF2qv+ae7l3sSNzfAv7Jq5PmXguOmOfpue4jbDfX6nbg1/TqC9sNfpLC+cEBHQefJowfytkMPUGM94XLvJ1fw8gveRAWAJrf9wKVgpTdUhtvLVwsmp7YUUP5/XjOmtYY5VmbUKyOcCuqgmjfj/go29Dm5Olz+LhLwAclVx0LkkS4Vfl0uLf7vQGaw0CWpy+inYsX0/5yM3kCR1oG6nT/LJva7TGp+YC9kFBp5tRcoM6fCZE8HWHeKJLxBg== 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 8/14/23, David Hildenbrand wrote: > On 13.08.23 14:33, Mateusz Guzik wrote: >> xchg originated in 6e399cd144d8 ("prctl: avoid using mmap_sem for >> exe_file serialization"). While the commit message does not explain >> *why* the change, clearly the intent was to use mmap_sem less in this >> codepath. I found the original submission [1] which ultimately claims it >> cleans things up. > > More details are apparently in v1 of that patch: > > https://lore.kernel.org/lkml/1424979417.10344.14.camel@stgolabs.net/ > > Regarding your patch: adding more mmap_write_lock() where avoidable, I'm > not so sure. > But exe_file access is already synchronized with the semaphore and your own commit added a mmap_read_lock/mmap_read_unlock cycle after the xchg in question to accomodate this requirement. Then mmap_write_lock around the replacement is the obvious thing to do. > Your patch doesn't look (to me) like it is removing a lot of complexity. > The code in the current form makes the reader ask what prompts xchg + read-lock instead of mere write-locking. This is not a hot path either and afaics it can only cause contention if userspace is trying to abuse the interface to break the kernel, messing with a processs hard at work (which would be an extra argument to not play games on kernel side). That said, no, it does not remove "a lot of complexity". It does remove some though at no real downside that I can see. But then again, it is on people who insist on xchg to justify it. -- Mateusz Guzik