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 EBDAAC7EE29 for ; Thu, 25 May 2023 16:09:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60BE66B0074; Thu, 25 May 2023 12:09:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BD5A900003; Thu, 25 May 2023 12:09:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48304900002; Thu, 25 May 2023 12:09:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3ADC86B0074 for ; Thu, 25 May 2023 12:09:04 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E1988120CA8 for ; Thu, 25 May 2023 16:09:03 +0000 (UTC) X-FDA: 80829261366.27.AA2CC19 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf13.hostedemail.com (Postfix) with ESMTP id 59E9820045 for ; Thu, 25 May 2023 16:08:03 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=AGk2s27G; spf=pass (imf13.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685030883; a=rsa-sha256; cv=none; b=t+S6gtSZxO1Z4za5DKGll824XsKgQaGBzsMKjEkI1s8/sd2fz9nH9JPXbO+efilKTxl2hA 7ploNRea87oEgjPDAt/d7Y65sPmkMZ+tCmCB6/qbXsY13ABxg97AEoJ1FiO99Vq22zpch5 VammGaSsFhOv6iOTBANy12jXuNv57ss= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=AGk2s27G; spf=pass (imf13.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685030883; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8qTlSjkBOvu6ts2EQmZGpeTeiOlCCdoojabISpYKz8Q=; b=DS62XT+XXQy1noyY6g+OcdV7ibVtOR4wyMp3JUpLWdBnEH2Qy3GsKKD6XydG2QMAAVCGaF lXpc6QG3pc8vrwSOQ9yvJ7MqMtn78seA1/532KyliFEIQZUYNWQ/tN9nWIxQBvP+cvXggg xMALW8nDFsDWbqcrqv/KHg3TohcMWNo= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-510d1972d5aso4191341a12.0 for ; Thu, 25 May 2023 09:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1685030881; x=1687622881; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8qTlSjkBOvu6ts2EQmZGpeTeiOlCCdoojabISpYKz8Q=; b=AGk2s27G2D/0kgwo5c+BpzFkfLtAxtbQE1yVPDMfXZNOKrJByKQ7yx+zRbxblNbtD+ 8Z1iTAJxsDD1lmSntifWnI8Kh44nCNe+cwo7hzLzKktdK5rq2ri9fVZ5Nga+ck35byTo CuTcgw+BmvEQIpJIo9tKotMcVNZCKTKvyqf54= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685030881; x=1687622881; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8qTlSjkBOvu6ts2EQmZGpeTeiOlCCdoojabISpYKz8Q=; b=HnaxET9UhEsMaRArZcnkYiJCaj0tCwbYscrXSNY5+TtossIFeEIvIdiHHzTSYLnk9T TAEt0hF1IXJm6I4uGJNZjA/QsNhEUl30xPnk6dqH/MNxUGg6gdatGvM68hBtLLeNOYqE BOicurcrELpLiT29Lnj+9J241xYiYt780/NCKXyiY7u3zgWI6m+NSQWur3tTw9oja2Ye 2pKSAmBGLvnOdi+EH1IP9mjVkOHtY6mlV5TkuwadHs3oSLPqtKn8fdncvpd5QMOma+MZ W/Rg6OABbGbaYC3sqxEMWfbUtTb6JBal3lLVYCmSk002UyT7YImg/Yf0sLrrJG6t1b/G OZTw== X-Gm-Message-State: AC+VfDxV7vIBiiXbAi7nc9VX4YcW+iP5Sq5+/RbSuKXIp4kXMYeQMV+K nZBV/Of5PXjWAQmmVdEnvRxtSVFWX34XIvxOtS1P5LS9 X-Google-Smtp-Source: ACHHUZ4UNevumR48NCP3kqOyB9EviVzyU48AzArKWafyL4M6uydpomeOHmYleSHp402j5zdP6zViNA== X-Received: by 2002:aa7:d055:0:b0:510:e8d4:37c3 with SMTP id n21-20020aa7d055000000b00510e8d437c3mr5019720edo.3.1685030881516; Thu, 25 May 2023 09:08:01 -0700 (PDT) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com. [209.85.208.50]) by smtp.gmail.com with ESMTPSA id y23-20020aa7d517000000b0050bd2f16ef5sm683889edq.84.2023.05.25.09.08.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 May 2023 09:08:01 -0700 (PDT) Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-510e90d785fso4157410a12.2 for ; Thu, 25 May 2023 09:08:01 -0700 (PDT) X-Received: by 2002:a17:907:7faa:b0:96a:937c:5608 with SMTP id qk42-20020a1709077faa00b0096a937c5608mr2490223ejc.53.1685030860523; Thu, 25 May 2023 09:07:40 -0700 (PDT) MIME-Version: 1.0 References: <20230524213620.3509138-1-mcgrof@kernel.org> <20230524213620.3509138-3-mcgrof@kernel.org> <8fc5b26b-d2f6-0c8f-34a1-af085dbef155@suse.com> In-Reply-To: <8fc5b26b-d2f6-0c8f-34a1-af085dbef155@suse.com> From: Linus Torvalds Date: Thu, 25 May 2023 09:07:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] module: add support to avoid duplicates early on load To: Petr Pavlu Cc: Luis Chamberlain , gregkh@linuxfoundation.org, rafael@kernel.org, song@kernel.org, lucas.de.marchi@gmail.com, lucas.demarchi@intel.com, christophe.leroy@csgroup.eu, peterz@infradead.org, rppt@kernel.org, dave@stgolabs.net, willy@infradead.org, vbabka@suse.cz, mhocko@suse.com, dave.hansen@linux.intel.com, colin.i.king@gmail.com, jim.cromie@gmail.com, catalin.marinas@arm.com, jbaron@akamai.com, rick.p.edgecombe@intel.com, yujie.liu@intel.com, david@redhat.com, tglx@linutronix.de, hch@lst.de, patches@lists.linux.dev, linux-modules@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, pmladek@suse.com, prarit@redhat.com, lennart@poettering.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 59E9820045 X-Stat-Signature: tfh5cpdnihktfkyngkx8k9smu83fgs7t X-Rspam-User: X-HE-Tag: 1685030883-264398 X-HE-Meta: U2FsdGVkX1/SIEHcNH7tGTS4BvjZhxS4aYLLEr1WVjzs7ltLLvgGiXrdI0ohy2IYA/NSJOK9ejLti/EQ2npEQTMACC/6r/uN3nRGmNEhShGifiamhb92mzb9EQ0IlXztvmnMPu5M3ESRdayWhrtOHUrZLzLUTifXorBGQlkBqSaL0EQxFAkmMm78aR/fti/PDis+5lEfmPpqHc3+lucO+tXrJxZma5tNYbk6tT6a2unbhl0yRnJazLn/cPM7eBkm7hY/1PaEwWPMOqQiPR8j07t3e8aJMdpXqkeu6KnsGNo60fbSOjFwzkIhT9nTn/oQSI4f1kHXTMBU92yB/krhEdNOsvUVoCZu7NM+B7FPZWWE6EDQifY54n+fagGdwPgJnqI3udlLSJhf1K7EeHd9Giji0N3yNcBhz6W8EnZSF8/t6OUx9/IU6aPi1BZWq8I4YA+6oX9CGF6uIgbHuh55ma28dfXKyQo9Ibr4IIx/ofdwy7RdPpsB1gc7fvTZv7O78LRuPWRRhZVRqF0lLKPFh9FrH+kvUcvv15mbhNZzeFy99GyoX/I0Y1l7xTWmvIfGM8UE1icbrAkF00vbvOZ7OLeB9TTRBZb/k2IK671WGcKrtNnx4D4gYTj3mneynfb3nUdcXre8dvUzTyqwVLLyUQUD/XaWKRgzKuAJ/dNqoR298Uvge1yfE1Z0H+pM2bQn8oEgX3rOOAvQA1h8nwZLDBYf5V9A8oyZ49xq3jXHzv+LwVCCD+X5SKhrBZ0UOLfgH6AsVwZ68NiAOjxhUNE8VME+dEDI8cRcn4Ncqpq50c5kyZM8RFGWFf77g92JN+egcQex9MlD0zvaz/S74Sj4sDIV7s3TI2qgtJDrIrDBrPGfp/GU/trGTqtzzoBDtLz7uI6DGoRcxqQzgVB6mn+Xwty5+eSd3F9JlN59q/qZOHUhsLxxXIuAUn3ycLCYWmLXgu8BezpdHryswiBR8Pl 7KBaWRaV XIjoDTCT5QU1o8CxfshiaexBxaCH0AUotM2AWfkUbznn+wRGGl8WVh677CBk95+MFPuD36GUTip1tRp2G1xf8NiFLe30MmwLJA+71E2aSG/xSw9oZjBauwvR6c5BrgHgTu+txHRXQKVBS+YE8M63toWQwaVQmOfh2M12WXrWbKBvdY6Rz2Ore6+JmlXj+of9AtJII2qKONVnd06Hz3RUD91YpKQitKw+NRyVOsCEUfIFHZqGLn4+NENvmlsvh76fDEA7HkfJ0WdsX6BC2RiMpqtu641GuvVj2bOYdf1jnbDpdHIcNkCuFCdIrZNXvkyan55/vQzQM+CqWs9VTRoZcxOAxMD+qCe4XoiGJ3zyOUUWZEApNvo2pMstBKInGrtaTT4pU0l0vvdXZRdYvFxKec26TV2bPs1DL6yVeZSsyMYKTDc05hZHWcbBfHHrj3gax1dBL+Sq6y5YqYF3MJlLIeiNSEx7fP0ipeBDueYMPzPwmA9/Hs8NfMQQ8gELlbm/Z/q9T7mZ7HdYwYZXpOlXtkmsxXLU57QJ9IkdXh+wnIaeRdPZuOj2Zi9iTn1JhIOAnworsBj6njjh9dMVX+ln0NB0R4srTgv1uZyaAk1Cf4BDdsgcZV7BbgN114GBMc7p8RQM4Ocmga2bQIjvFfH4ViSe5vWkucMRFyP+2EC/0cs0LsyBAyKYc1KjPoLR5rBi4vSJnoqPiYREsPq4= 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 Thu, May 25, 2023 at 4:40=E2=80=AFAM Petr Pavlu wr= ote: > > kmod normally uses finit_module() only if a module is not compressed, > otherwise it decompresses it first and then invokes init_module(). Note that it would probably be good to teach Fedora and SuSE to use the kernel-side decompression, if only because we have it and would like to try to avoid using the old "load contents from user memory". Mainly because it allows security modules to actively check for tampering (ie things like verity etc). Long-term, it would be good to just deprecate the old init_module() entirely. But yes: > It means that these and similarly organized distributions end up using > init_module(), and adding complexity to optimize finit_module() wouldn't > actually help in their case. Yeah, I think the real bug is absolutely in udev, and trying to load the same module hundreds of times is very very wrong. So I think the "mitigate it in the kernel" is at most a quick hack to fix user-space brokenness. And I don't think 1/2 is acceptable as that "quick hack". Not at all. It also seems fundamentally buggy, as it uses purely the inode number as the file identity, which means that it does bad things across filesystem limits. That said, I posted an alternate patch that I think _is_ valid as that quick hack. I don't love it, but it sure is simpler (and avoids the i_ino bug): https://lore.kernel.org/lkml/CAHk-=3DwgKu=3DtJf1bm_dtme4Hde4zTB=3D_7Edg= R8avsDRK4_jD+uA@mail.gmail.com/ that patch hasn't seen any testing, and for all I know it won't even boot because of some thinko, but I think it would be acceptable as a workaround if it does work. But no, it's not some kind of "fix" for the bug, and yes, using init_module() rather than finit_module() will circumvent the quick hack. The true fix would be for udev to do proper handling of its data structures instead of randomly spraying duplicate module loading events. I don't know why udev does what it does. From what Luis told me, apparently it's just forking stuff and keeping all its data structures in memory, and has no actual consistency or locking or memory of what it has done. Luis pointed me at https://lore.kernel.org/all/23bd0ce6-ef78-1cd8-1f21-0e706a00424a@suse.c= om/T/#u for some udev background. It's been about a decade since I looked at udev sources, and none of this encourages me to take a second look, so all of the above may be me misunderstanding just exactly what the udev problem is. But for that 'finit' case, we *could* try that simple hack of mine. I say "hack", but the patch really is pretty simple, and the concept of "exclusive special access" certainly is not some hack in itself. It's just not anything we've ever done before. So the hackishness from that exclusive_deny_write_access() thing in my patch is mainly that it shouldn't be needed at all (and that the exclusivity should probably be set some other way). Comments welcome. Linus