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 BFC7BC54E41 for ; Mon, 4 Mar 2024 08:45:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E9AE86B0092; Mon, 4 Mar 2024 03:45:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4B3A6B00A1; Mon, 4 Mar 2024 03:45:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CED206B009C; Mon, 4 Mar 2024 03:45:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BE2696B0092 for ; Mon, 4 Mar 2024 03:45:40 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 904771209F8 for ; Mon, 4 Mar 2024 08:45:40 +0000 (UTC) X-FDA: 81858723240.26.BEBB07A Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf07.hostedemail.com (Postfix) with ESMTP id 52C9440006 for ; Mon, 4 Mar 2024 08:45:36 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf07.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709541938; 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; bh=OCDBGDkz2tLdAN5KOFiloZHr8ehyPDliPED+0SW7RQk=; b=ObU4dEP1K4ovQ+75I546vpNbZaq5SabN4cMx1xfchYNc6iYBDwSQvYcgB4Vm8bxLJSjvbU NZJMsu4FLmpFV8TM1jk5ibXn/Iw78dpslUlbGtnkb1ml8CeKadTDGv7E94g55LrlcENQWj oJDZy52u8zThpGHdWFJYiLL7ly51MZc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf07.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709541938; a=rsa-sha256; cv=none; b=giGxY597FmLPkrho9kmHQW/hWTdlyMEMeNy/T0PjdQsnOFeS85D9B11XH3PjwkhXd3hVS1 s0Yq0aeta6ZWszri3EMhFCzagRicuKYPew9Wwlx17POwQ6Vl70EZYWInFAHYkEH5SaMOOW +ItkHZ5tO21naPBGlrdKB7SN1keOBKE= Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4TpC0X6tGKzNlpP; Mon, 4 Mar 2024 16:43:56 +0800 (CST) Received: from kwepemm600017.china.huawei.com (unknown [7.193.23.234]) by mail.maildlp.com (Postfix) with ESMTPS id CF891140415; Mon, 4 Mar 2024 16:45:32 +0800 (CST) Received: from [10.174.179.234] (10.174.179.234) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 4 Mar 2024 16:45:31 +0800 Message-ID: Date: Mon, 4 Mar 2024 16:45:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [bug report] dead loop in generic_perform_write() //Re: [PATCH v7 07/12] iov_iter: Convert iterate*() to inline funcs To: Linus Torvalds CC: Al Viro , David Howells , Jens Axboe , Christoph Hellwig , Christian Brauner , David Laight , Matthew Wilcox , Jeff Layton , , , , , , Kefeng Wang References: <20230925120309.1731676-1-dhowells@redhat.com> <20230925120309.1731676-8-dhowells@redhat.com> <4e80924d-9c85-f13a-722a-6a5d2b1c225a@huawei.com> From: Tong Tiangen In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600017.china.huawei.com (7.193.23.234) X-Rspamd-Queue-Id: 52C9440006 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 1yomxmxx5oso45ihbcnadknp3hs34eyq X-HE-Tag: 1709541936-177498 X-HE-Meta: U2FsdGVkX1+IVBOoGNzeao6u7LKRHbk0daDYikZ20GIIymp9Opxh5tNFZBq4BtOeKjleqhCdh5AeoNnSE4Fn5PGjBOJfOBrf2UIjjLlYdEN6AM9uiMjSdH3dkzDY5/+Da/r5WW1ArG6jAAn1bZHEw/rwRlLtSpxWutZSwn4hqBx5/e2TJblI+7d9lSQOsUChrhZgHfDdgGeCzJAGaUFbxRt4ixjA3hDW6bdnBw4OVPHE6RObY9sm4GfhZJMj/EF8D+i0igavXIetOkwno5yUY5pJic1j4Jwa9jQGDrrcuW2jWBl5TJnLjtmweW9Bjl5aDkoWHKYhZ6r779yhi9JnKRUnmj2fpRmw0Z7j13WJobO/vym3lrCs2gzsVelutWatLRgttg4BMhNAhsMLPhH7MIWdDElXOFY0EIE5jF8dMtvB8EbpDiZe+kYv7j/cK6hs4HAqPJePVNFdbKdOf7OzVxR7vsTAitnMG1e3q3LPGYet6m3pEvG00wiI/JEHsgqH/cNq6MPK8RlpzRSe8Kyu983Xk9Vm6VNPiW92/dRPQo0mb9OY9DS5N6fdmKZ1xGq1HbPP7m7OhnW9jgJKyolCqJBEaQLzcgZkm7/h/KGnRhx0UNsPfP9WJDDrDEsOtczInbEZ5I54Vo1vQm/cjwW98g/sd3zYnjr6oCjICrLS3DpG0fYgoixb1EWuU+2fQiwO3a0OrAobm8CPYnnvSren4rRwmUCBzLalaZcDjlnVIom2n4/fRh3RQTHc4QF4flDA5xCTH33viNpsn72D4Hl6BcBvbk3SqHDRRUPQWXv3NzgbuDsOB/UpQiW/sisvtl20VEbhowIxo/9vjOXPMZRt/4j0X6HaN9M0EOFzXhjSum8= 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: 在 2024/3/3 2:06, Linus Torvalds 写道: > On Sat, 2 Mar 2024 at 01:37, Tong Tiangen wrote: >> >> I think this solution has two impacts: >> 1. Although it is not a performance-critical path, the CPU usage may be >> affected by one more memory copy in some large-memory applications. > > Compared to the IO, the extra memory copy is a non-issue. > > If anything, getting rid of the "copy_mc" flag removes extra code in a > much more important path (ie the normal iov_iter code). Indeed. I'll test this solution. Theoretically, it should solve the problem. > >> 2. If a hardware memory error occurs in "good location" and the >> ".copy_mc" is removed, the kernel will panic. > > That's always true. We do not support non-recoverable machine checks > on kernel memory. Never have, and realistically probably never will. > > In fact, as far as I know, the hardware that caused all this code in > the first place no longer exists, and never really made it to wide > production. Yes. There is a low probability that the newly applied memory is faulty. Thanks, Tong. > > The machine checks in question happened on pmem, now killed by Intel. > It's possible that somebody wants to use it for something else, but > let's hope any future implementations are less broken than the > unbelievable sh*tshow that caused all this code in the first place. > > The whole copy_mc_to_kernel() mess exists mainly due to broken pmem > devices along with old and broken CPU's that did not deal correctly > with machine checks inside the regular memory copy ('rep movs') code, > and caused hung machines. > > IOW, notice how 'copy_mc_to_kernel()' just becomes a regular > 'memcpy()' on fixed hardware, and how we have that disgusting > copy_mc_fragile_key that gets enabled for older CPU cores. > > And yes, we then have copy_mc_enhanced_fast_string() which isn't > *that* disgusting, and that actually handles machine checks properly > on more modern hardware, but it's still very much "the hardware is > misdesiged, it has no testing, and nobody sane should depend on this" > > In other words, it's the usual "Enterprise Hardware" situation. Looks > fancy on paper, costs an arm and a leg, and the reality is just sad, > sad, sad. > > Linus > .