From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id 52D1D440D03 for ; Thu, 9 Nov 2017 13:58:45 -0500 (EST) Received: by mail-oi0-f69.google.com with SMTP id b189so5075880oia.10 for ; Thu, 09 Nov 2017 10:58:45 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id e44sor774564otd.331.2017.11.09.10.58.44 for (Google Transport Security); Thu, 09 Nov 2017 10:58:44 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20171108095909.GA7390@infradead.org> <20171108150447.GA10374@infradead.org> <20171108153522.GB24548@infradead.org> <20171108174747.GA12199@infradead.org> From: Dan Williams Date: Thu, 9 Nov 2017 10:58:43 -0800 Message-ID: Subject: Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Mikulas Patocka Cc: Christoph Hellwig , "linux-nvdimm@lists.01.org" , Christoph Hellwig , Linux MM , dm-devel@redhat.com, Ross Zwisler , Laura Abbott , "Kirill A . Shutemov" , "Luck, Tony" On Thu, Nov 9, 2017 at 10:51 AM, Mikulas Patocka wrote: [..] >> The drivers don't need to react, once the pages are pinned for dma the >> hot-unplug will not progress until all those page references are >> dropped. > > I am not talking about moving pages here, I'm talking about possible > hardware errors in persistent memory. In this situation, the storage > controller receives an error on the bus - and the question is, how will it > react. Ideally, it should abort just this transfer and return an error > that the driver will propagate up. But I'm skeptical that someone is > really testing the controllers and drivers for this possiblity. This is something that drive controllers already need to deal with today on DRAM, but I suspect you are right because in general error-path testing in drivers is rare to non-existent in Linux. We can endeavor to do better with persistent memory where we have some explicit error injection facilities defined in ACPI that might enjoy wider support than the existing EINJ facility. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org