Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp6746536ybl; Wed, 15 Jan 2020 09:32:18 -0800 (PST) X-Google-Smtp-Source: APXvYqx1/F/04y8JhbJF4/90xz4YjfL8D4lKqoWQdAhIG0ZDhpmQ07/dmjqngBpN9MP7WHm1I3mU X-Received: by 2002:aca:5487:: with SMTP id i129mr673067oib.167.1579109538868; Wed, 15 Jan 2020 09:32:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579109538; cv=none; d=google.com; s=arc-20160816; b=Fu6qeqyZ7Q8ViY5MnNhP1KhJrl/r+J7bN0HWMpk+hZPg3g9GF+qCqncZJIwM6oo0ft 6dbMQJ9zGZeZMDhBTrFw5JsF6aULIjzOGvsRbhLKQ6H31IYPwRktdVMN0n7C6lrrhu4S YJXclchG2kraKQZp8Ehq5gtn6xgQ8non+g7PcZnhRIYQ4SZ2uixABDCczPU25pQSUA5Z sv5BVW8L35FUFYBp2E0pYGsD0Iark6tBCyFXTAUepIZ9UUC2/Qi7Kp7Xd6AT3ST9DHNI sPm8OWDvUu7ETuO2W7cfDrwJkfOLFJ/Pl0lsPzq0gH4y3180kKQ8jiUWjGGy0ZzAcClR pX4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:from:references:cc:to:subject; bh=onptSt9qSAoVoYKE9kzF6TiCxGXi6BQ27t0OXVP/9vs=; b=Q30lNz6ER6CMro0eslL/zWUImDd17TYEF3XyQ3p5LrSEKIkh+IiqH/nwYSHKojTs7V +oL1MbBRXF3DMD+o4kvPxX5qditA26098pNe5GFdXB89ZherZpOieGxU6dU6lDNgO7W2 A5P1aA07DMfF/zLytAMWnFD0i0JWSu1ZlbZw4dcBPzXlu35PT0sBLV0JG6ja/Iw9f5Mz buXZYZOwqA0NET7uOrnZ4uWraMJn20y8A0n/3o4MAQXiT1tRP0N1f1y8QaVSpcMqOWa5 yr3hIVqYBKUsuFn4Kw4YmtOvlSkASEO+QkNfBlx40PsuRSSX2nf4IwJDdl89Mey78sfz d0yA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k10si12922770otf.237.2020.01.15.09.32.06; Wed, 15 Jan 2020 09:32:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728913AbgAORbL (ORCPT + 99 others); Wed, 15 Jan 2020 12:31:11 -0500 Received: from mailout.easymail.ca ([64.68.200.34]:40796 "EHLO mailout.easymail.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726418AbgAORbL (ORCPT ); Wed, 15 Jan 2020 12:31:11 -0500 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 9B58021A7A; Wed, 15 Jan 2020 17:31:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at emo06-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo06-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Cya_KbpAvt9; Wed, 15 Jan 2020 17:31:09 +0000 (UTC) Received: from mail.gonehiking.org (c-24-9-64-241.hsd1.co.comcast.net [24.9.64.241]) by mailout.easymail.ca (Postfix) with ESMTPA id CACE220A05; Wed, 15 Jan 2020 17:30:57 +0000 (UTC) Received: from [192.168.1.4] (rhapsody.internal [192.168.1.4]) by mail.gonehiking.org (Postfix) with ESMTP id D9A3E3F012; Wed, 15 Jan 2020 10:30:56 -0700 (MST) Subject: Re: [RFC PATCH] PCI, kdump: Clear bus master bit upon shutdown in kdump kernel To: Kairui Song , Deepa Dinamani Cc: Baoquan He , linux-pci@vger.kernel.org, kexec@lists.infradead.org, Jerry Hoemann , Randy Wright , Linux Kernel Mailing List , Bjorn Helgaas References: <20200110214217.GA88274@google.com> <20200110230003.GB1875851@anatevka.americas.hpqcorp.net> <20200111005041.GB19291@MiWiFi-R3L-srv> From: Khalid Aziz Autocrypt: addr=khalid@gonehiking.org; prefer-encrypt=mutual; keydata= mQINBFA5V58BEADa1EDo4fqJ3PMxVmv0ZkyezncGLKX6N7Dy16P6J0XlysqHZANmLR98yUk4 1rpAY/Sj/+dhHy4AeMWT/E+f/5vZeUc4PXN2xqOlkpANPuFjQ/0I1KI2csPdD0ZHMhsXRKeN v32eOBivxyV0ZHUzO6wLie/VZHeem2r35mRrpOBsMLVvcQpmlkIByStXGpV4uiBgUfwE9zgo OSZ6m3sQnbqE7oSGJaFdqhusrtWesH5QK5gVmsQoIrkOt3Al5MvwnTPKNX5++Hbi+SaavCrO DBoJolWd5R+H8aRpBh5B5R2XbIS8ELGJZfqV+bb1BRKeo0kvCi7G6G4X//YNsgLv7Xl0+Aiw Iu/ybxI1d4AtBE9yZlyG21q4LnO93lCMJz/XqpcyG7DtrWTVfAFaF5Xl1GT+BKPEJcI2NnYn GIXydyh7glBjI8GAZA/8aJ+Y3OCQtVxEub5gyx/6oKcM12lpbztVFnB8+S/+WLbHLxm/t8l+ Rg+Y4jCNm3zB60Vzlz8sj1NQbjqZYBtBbmpy7DzYTAbE3P7P+pmvWC2AevljxepR42hToIY0 sxPAX00K+UzTUwXb2Fxvw37ibC5wk3t7d/IC0OLV+X29vyhmuwZ0K1+oKeI34ESlyU9Nk7sy c1WJmk71XIoxJhObOiXmZIvWaOJkUM2yZ2onXtDM45YZ8kyYTwARAQABtCNLaGFsaWQgQXpp eiA8a2hhbGlkQGdvbmVoaWtpbmcub3JnPokCOgQTAQgAJAIbAwULCQgHAwUVCgkICwUWAgMB AAIeAQIXgAUCUDlYcgIZAQAKCRDNWKGxftAz+mCdD/4s/LpQAYcoZ7TwwQnZFNHNZmVQ2+li 3sht1MnFNndcCzVXHSWd/fh00z2du3ccPl51fXU4lHbiG3ZyrjX2Umx48C20Xg8gbmdUBzq4 9+s12COrgwgsLyWZAXzCMWYXOn9ijPHeSQSq1XYj8p2w4oVjMa/QfGueKiJ5a14yhCwye2AM f5o8uDLf+UNPgJIYAGJ46fT6k5OzXGVIgIGmMZCbYPhhSAvLKBfLaIFd5Bu6sPjp0tJDXJd8 pG831Kalbqxk7e08FZ76opzWF9x/ZjLPfTtr4xiVvx+f9g/5E83/A5SvgKyYHdb3Nevz0nvn MqQIVfZFPUAQfGxdWgRsFCudl6i9wEGYTcOGe00t7JPbYolLlvdn+tA+BCE5jW+4cFg3HmIf YFchQtp+AGxDXG3lwJcNwk0/x+Py3vwlZIVXbdxXqYc7raaO/+us8GSlnsO+hzC3TQE2E/Hy n45FDXgl51rV6euNcDRFUWGE0d/25oKBXGNHm+l/MRvV8mAdg3iTiy2+tAKMYmg0PykiNsjD b3P5sMtqeDxr3epMO+dO6+GYzZsWU2YplWGGzEKI8sn1CrPsJzcMJDoWUv6v3YL+YKnwSyl1 Q1Dlo+K9FeALqBE5FTDlwWPh2SSIlRtHEf8EynUqLSCjOtRhykmqAn+mzIQk+hIy6a0to9iX uLRdVbkCDQRQOVefARAAsdGTEi98RDUGFrxK5ai2R2t9XukLLRbRmwyYYx7sc7eYp7W4zbnI W6J+hKv3aQsk0C0Em4QCHf9vXOH7dGrgkfpvG6aQlTMRWnmiVY99V9jTZGwK619fpmFXgdAt WFPMeNKVGkYzyMMjGQ4YbfDcy04BSH2fEok0jx7Jjjm0U+LtSJL8fU4tWhlkKHtO1oQ9Y9HH Uie/D/90TYm1nh7TBlEn0I347zoFHw1YwRO13xcTCh4SL6XaQuggofvlim4rhwSN/I19wK3i YwAm3BTBzvJGXbauW0HiLygOvrvXiuUbyugMksKFI9DMPRbDiVgCqe0lpUVW3/0ynpFwFKeR FyDouBc2gOx8UTbcFRceOEew9eNMhzKJ2cvIDqXqIIvwEBrA+o92VkFmRG78PleBr0E8WH2/ /H/MI3yrHD4F4vTRiPwpJ1sO/JUKjOdfZonDF6Hu/Beb0U5coW6u7ENKBmaQ/nO1pHrsqZp+ 2ErG02yOHF5wDWxxgbd4jgcNTKJiY9F1cdKP+NbWW/rnJgem8qYI3a4VkIkFT5BE2eYLvZlR cIzWc/ve/RoQh6jzXD0T08whoajZ1Y3yFQ8oyLSFt8ybxF0b5XryL2RVeHQTkE8NKwoGVYTn ER+o7x2sUGbIkjHrE4Gq2cooEl9lMv6I5TEkvP1E5hiZFJWYYnrXa/cAEQEAAYkCHwQYAQgA CQUCUDlXnwIbDAAKCRDNWKGxftAz+reUEACQ+rz2AlVZZcUdMxWoiHqJTb5JnaF7RBIBt6Ia LB9triebZ7GGW+dVPnLW0ZR1X3gTaswo0pSFU9ofHkG2WKoYM8FbzSR031k2NNk/CR0lw5Bh whAUZ0w2jgF4Lr+u8u6zU7Qc2dKEIa5rpINPYDYrJpRrRvNne7sj5ZoWNp5ctl8NBory6s3b bXvQ8zlMxx42oF4ouCcWtrm0mg3Zk3SQQSVn/MIGCafk8HdwtYsHpGmNEVn0hJKvUP6lAGGS uDDmwP+Q+ThOq6b6uIDPKZzYSaa9TmL4YIUY8OTjONJ0FLOQl7DsCVY9UIHF61AKOSrdgCJm N3d5lXevKWeYa+v6U7QXxM53e1L+6h1CSABlICA09WJP0Fy7ZOTvVjlJ3ApO0Oqsi8iArScp fbUuQYfPdk/QjyIzqvzklDfeH95HXLYEq8g+u7nf9jzRgff5230YW7BW0Xa94FPLXyHSc85T E1CNnmSCtgX15U67Grz03Hp9O29Dlg2XFGr9rK46Caph3seP5dBFjvPXIEC2lmyRDFPmw4yw KQczTkg+QRkC4j/CEFXw0EkwR8tDAPW/NVnWr/KSnR/qzdA4RRuevLSK0SYSouLQr4IoxAuj nniu8LClUU5YxbF57rmw5bPlMrBNhO5arD8/b/XxLx/4jGQrcYM+VrMKALwKvPfj20mB6A== Message-ID: Date: Wed, 15 Jan 2020 10:30:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/13/20 10:07 AM, Kairui Song wrote: > On Sun, Jan 12, 2020 at 2:33 AM Deepa Dinamani wrote: >> >>> Hi, there are some previous works about this issue, reset PCI devices >>> in kdump kernel to stop ongoing DMA: >>> >>> [v7,0/5] Reset PCIe devices to address DMA problem on kdump with iommu >>> https://lore.kernel.org/patchwork/cover/343767/ >>> >>> [v2] PCI: Reset PCIe devices to stop ongoing DMA >>> https://lore.kernel.org/patchwork/patch/379191/ >>> >>> And didn't get merged, that patch are trying to fix some DMAR error >>> problem, but resetting devices is a bit too destructive, and the >>> problem is later fixed in IOMMU side. And in most case the DMA seems >>> harmless, as they targets first kernel's memory and kdump kernel only >>> live in crash memory. >> >> I was going to ask the same. If the kdump kernel had IOMMU on, would >> that still be a problem? > > It will still fail, doing DMA is not a problem, it only go wrong when > a device's upstream bridge is mistakenly shutdown before the device > shutdown. > >> >>> Also, by the time kdump kernel is able to scan and reset devices, >>> there are already a very large time window where things could go >>> wrong. >>> >>> The currently problem observed only happens upon kdump kernel >>> shutdown, as the upper bridge is disabled before the device is >>> disabledm so DMA will raise error. It's more like a problem of wrong >>> device shutting down order. >> >> The way it was described earlier "During this time, the SUT sometimes >> gets a PCI error that raises an NMI." suggests that it isn't really >> restricted to kexec/kdump. >> Any attached device without an active driver might attempt spurious or >> malicious DMA and trigger the same during normal operation. >> Do you have available some more reporting of what happens during the >> PCIe error handling? > > Let me add more info about this: > > On the machine where I can reproduce this issue, the first kernel > always runs fine, and kdump kernel works fine during dumping the > vmcore, even if I keep the kdump kernel running for hours, nothing > goes wrong. If there are DMA during normal operation that will cause > problem, this should have exposed it. > This is the part that is puzzling me. Error shows up only when kdump kernel is being shut down. kdump kernel can run for hours without this issue. What is the operation from downstream device that is resulting in uncorrectable error - is it indeed a DMA request? Why does that operation from downstream device not happen until shutdown? I just want to make sure we fix the right problem in the right way. -- Khalid