Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752793AbbHSXOs (ORCPT ); Wed, 19 Aug 2015 19:14:48 -0400 Received: from ozlabs.org ([103.22.144.67]:56192 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbbHSXOR (ORCPT ); Wed, 19 Aug 2015 19:14:17 -0400 X-powerpc-patch-notification: thanks X-powerpc-patch-commit: d9232a3da8683cd9c9854a858bcca968fe5f3bca In-Reply-To: <1437633836-5051-1-git-send-email-imunsie@au.ibm.com> To: Ian Munsie From: Michael Ellerman Cc: Matt Ochs , linuxppc-dev , mikey , linux-kernel , Ian Munsie Subject: Re: cxl: Add alternate MMIO error handling Message-Id: <20150819231416.858091409B7@ozlabs.org> Date: Thu, 20 Aug 2015 09:14:16 +1000 (AEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2098 Lines: 44 On Thu, 2015-23-07 at 06:43:56 UTC, Ian Munsie wrote: > From: Ian Munsie > > userspace programs using cxl currently have to use two strategies for > dealing with MMIO errors simultaneously. They have to check every read > for a return of all Fs in case the adapter has gone away and the kernel > has not yet noticed, and they have to deal with SIGBUS in case the > kernel has already noticed, invalidated the mapping and marked the > context as failed. > > In order to simplify things, this patch adds an alternative approach > where the kernel will return a page filled with Fs instead of delivering > a SIGBUS. This allows userspace to only need to deal with one of these > two error paths, and is intended for use in libraries that use cxl > transparently and may not be able to safely install a signal handler. > > This approach will only work if certain constraints are met. Namely, if > the application is both reading and writing to an address in the problem > state area it cannot assume that a non-FF read is OK, as it may just be > reading out a value it has previously written. Further - since only one > page is used per context a write to a given offset would be visible when > reading the same offset from a different page in the mapping (this only > applies within a single context, not between contexts). > > An application could deal with this by e.g. making sure it also reads > from a read-only offset after any reads to a read/write offset. > > Due to these constraints, this functionality must be explicitly > requested by userspace when starting the context by passing in the > CXL_START_WORK_ERR_FF flag. > > Signed-off-by: Ian Munsie > Acked-by: Michael Neuling Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/d9232a3da8683cd9c985 cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/