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 A0C81C5478C for ; Sat, 2 Mar 2024 18:07:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13DAE6B009C; Sat, 2 Mar 2024 13:07:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EE2E6B009D; Sat, 2 Mar 2024 13:07:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF8B46B009E; Sat, 2 Mar 2024 13:07:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DCFA86B009C for ; Sat, 2 Mar 2024 13:07:18 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 817C9A0BD4 for ; Sat, 2 Mar 2024 18:07:18 +0000 (UTC) X-FDA: 81852880956.18.F6994C7 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf16.hostedemail.com (Postfix) with ESMTP id 8DFE3180008 for ; Sat, 2 Mar 2024 18:07:16 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=IPZwkWES; spf=pass (imf16.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.51 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=1709402836; 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=tgHiAUIVGDD+1DgrVyftk8s8h5JugoTCX2MAvO9xGEU=; b=Wcg67802kOstYJj4la1vvnaAPQLeizA/X987clOnjK22GcqsxWyfP00ts6uWt+6DdiNPxl E9MFB2EW7Pgd/8ijaCve7bSpyVapkbLlgPb7Bg8iJjz/w5tjZQ+IBL8epboYpUJaEijjTl dMIKMD5mqNv4+piGv7iKH+66o9fp3mQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709402836; a=rsa-sha256; cv=none; b=EC0aJGb4/IIQI9yA7w2btu0tF1NfjEYMOMjrwoViRvifJDTUfzd3mjb1plB9ctJLiG08Y9 kIz0Ts+PeSdUnYZOHreDwOKRRqJ123omGv68T6tgxP2lBY+vL8E1978H0SZUy2wxqjHp7r JSkR8MV1W3+oJJZg1Dma1BTL+1y1b8E= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=IPZwkWES; spf=pass (imf16.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.51 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-51340e89df1so146835e87.1 for ; Sat, 02 Mar 2024 10:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1709402834; x=1710007634; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tgHiAUIVGDD+1DgrVyftk8s8h5JugoTCX2MAvO9xGEU=; b=IPZwkWES9wtX7zIzYF7oJY894DL2/zG7TM391PUFrQOkgXsOyeV6Do++EB+VNea21t 6Gtz23P2OgVQmAvYnER6J4TWCVzvrXQfYUuUnB50eecb7wdZP8jpVvUg+shBAu4roobd 3xdTUVGnGgNRdRwaTEgcPJLIm7JBVo+ut8zoI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709402834; x=1710007634; h=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=tgHiAUIVGDD+1DgrVyftk8s8h5JugoTCX2MAvO9xGEU=; b=DEsvIF+M4MgmwK/Qc5DipScEB/kkPpCsLd30fBwGtp7vuubDA/yNiZAJ/I8hRtrwyH 99ZTGv1S/fWaiKAgaFWR5qdtRdkNyvbfdIJzeLB0FN+vMQ26MHu3/+WvYvu2sO4C+ZCn ZRTV1jzo9NsaaSo0oNgcdEwjZfWsWqFHX5BnYaR2oAY7kKx21pU6r+6cJ7VT9+Iaoi08 I5vXMDS0ClkqvSkojZwW51Z3DS/TbctaylRg7/ESAgs9+zWrRmC/GSS79KTRojvcScKG DE83SIbdoWHvUcEw2G1upAryiDUSB0R7mm6T1sgisU3uTIpyY+lCLnGqEbmT50/6lBDZ umKw== X-Forwarded-Encrypted: i=1; AJvYcCWWa7zGORc9EM3bd0j4Eh5kaoNpapltHHKsZUPMPQL7BVlA/jEi/HdE4dH3itewxgdd5rw19S/z4XzrC9EmFRfHfJg= X-Gm-Message-State: AOJu0YwUEPYREtTsdA6ge+/US+F5QcRqdkPVrhExM+SW6o6QGM/ltxx1 YMo/r4AwVt/VUbib6r8Y8qQB/2CXizmpQLR2Du+JKowpg6RLS8oy7FbBG5+MlMGrJNdMyZ6SBI/ czE4LXw== X-Google-Smtp-Source: AGHT+IGZRtL3GJI0DNIq07vyWNs/SeRPL0224yZFb1JsmPPi5ixqczWNepeC/Uyac/QV7ePLsyND+g== X-Received: by 2002:a05:6512:402:b0:513:17bf:87d5 with SMTP id u2-20020a056512040200b0051317bf87d5mr3058051lfk.63.1709402834452; Sat, 02 Mar 2024 10:07:14 -0800 (PST) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id j22-20020a170906475600b00a449d6184dasm1608710ejs.6.2024.03.02.10.07.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Mar 2024 10:07:13 -0800 (PST) Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a43dba50bb7so456087866b.0 for ; Sat, 02 Mar 2024 10:07:12 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVQLfDeWsTI+IxeuChAx4Zv14cPYw8Bcym0XHoMb+1sYIAWjGiX9sGyxZw7H6HDstlkv1vjl7DVAyrK3cxzZWPiT3M= X-Received: by 2002:a17:906:2c53:b0:a44:f370:e2ce with SMTP id f19-20020a1709062c5300b00a44f370e2cemr785292ejh.16.1709402832627; Sat, 02 Mar 2024 10:07:12 -0800 (PST) MIME-Version: 1.0 References: <20230925120309.1731676-1-dhowells@redhat.com> <20230925120309.1731676-8-dhowells@redhat.com> <4e80924d-9c85-f13a-722a-6a5d2b1c225a@huawei.com> In-Reply-To: From: Linus Torvalds Date: Sat, 2 Mar 2024 10:06:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [bug report] dead loop in generic_perform_write() //Re: [PATCH v7 07/12] iov_iter: Convert iterate*() to inline funcs To: Tong Tiangen Cc: Al Viro , David Howells , Jens Axboe , Christoph Hellwig , Christian Brauner , David Laight , Matthew Wilcox , Jeff Layton , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kefeng Wang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8DFE3180008 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: t8gsmqq3w6otg5xackk3a1miku4mxs4j X-HE-Tag: 1709402836-820345 X-HE-Meta: U2FsdGVkX1/mHzMRox9Ik+5vflqU3UhfIH+AmX8ar5cCjkGVza3kS6wSYrX6RNHHzZL7Hd5ni5mK1nP3r1amWpG7jV7SrHmkGrMJS2lAF4UNAtKsELSONPWUStLkRIk9vVZEaZcoJyfQVdKQn2SpQ23UUu3BVRtlCR6RH/4LcDiHPn3zUp6/KAktX4XYYtnsKtxD4IBzyfzWJ5XxKsv67wQXBJs8imXbNoj5OJ3o+OTAOf7nOBbXbRwy2nh9lgfBIxyNyE0hlpg59sVGAExxUHbHX/I7g7n0kg+T3ToOvK/qaPFUrL+MBG3yVmTnJ0666B+GShSbrYQEJRq5HqJHK3iH0Iiqw7TFlyGmqvQ6kCwpuACMjMWVMrl/RjkbzGXBBNenOxhZJaYvSPPkFZaWIRj6klEHhV/SrjVZzcWAgPVu3eDLH0+MXVXJBCTM2aqvjcSg4hQuYb6bQ/t0ftmZrYUHuuOXxBJ8ax0mzVTvcMYsJm6/5yLxV8wV0/nNtZDnWL3qiyR+fbcWOewTEyQMtoRDlAsQ6IZmWqlVqhSqSZytkxoLb1RhhbFJ5DWA9Xf/IqCHLpP03tgzR2FaxrDSvCV7bMxi4iLcCHiX5VS4UB6oEM+y4SiNGpjyei601PZpTu5SnSWg0claE/oh2HsGTFx9w23BuFAl2Ung75DCG+GaGmzH98NQr3LYcadsFuveBU1tD14LvQlbqjMW5yawzK8+zjtEDEZEVChJJd88WRysSg6Em2/hEhKmDqSM/FKAGDx5GsCIs2vJxeWBOcynAbY0yBMjsiu5CcwKDPO+PYKtndRCRS9A4Aov1ipvjpjtxVLF7lxs4ygh8gOTzJ154DlhX2YWsFCjnoNg2ZUWKxs853d1xtbk/N7TgizruuVsMsec31mBAlnyBNOZf8s5Ww3+Xy/sg+OcLGFQ3Q79Jx/mX3ShUZ3PNT/YnKW4ZVUCJ81R7jeXrviulht32t7 wtmB6rVQ iD91P2tchmjuEDgI2x+kFbR2FWQt80ngeuz8u27nlPp4+eagdxOr6S6yZYkYbxiC0oRaRs1x3rJNA2OBzh3Yv2o3lCkrRMJReUe3NYeeFHDi9UzGWGW5mzJPagemP6t1g6Xe86vFKI4ZFpbZUIMxU2HgDvV06oa/1r+XxCYujFpO0SfH+AmBFcF6Oun0AC1S0rzmwK7BjOf2V7XCC3mSn2QPbF+3RW1DjQTr99507PR7hD+0vgIEQ3TsmavJo49B4awVX2V1RCsPhH+BoF3mrBNQ3WpguEHk9A1W6tsLATcElN30xA54VCA1mjGGmkC2hrdcH 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 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). > 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. 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