Received: by 10.192.165.148 with SMTP id m20csp3866816imm; Mon, 23 Apr 2018 13:59:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx49DPgS4xVSNPU5hR1W5WD6pdtCs226cVABX8froiEx91UgxGF12EK3D+KJe6qI5OPO+sqUF X-Received: by 2002:a17:902:6bc3:: with SMTP id m3-v6mr21765867plt.363.1524517142110; Mon, 23 Apr 2018 13:59:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524517142; cv=none; d=google.com; s=arc-20160816; b=tNrD5pJ05xAenKauTD8A0icC+G4o/YADDOwNuYktI2Lh62LBLqx8sFAtj8r2f6Cwgd ynb1C+lyUQ8QizRtzptqLSFUs7Jo3vqRDOhbN8oqCSmDN/LH5pgmvoExdZO/+2xk+5Fv epvGSCFIs6Ja+pIYdondkpfNA6UFxO3fDmW8pQn6Mr9GT419yo3e8ZaK7Sa2O8QskILc l/WwsPLRicHshhaPuo2llUMWXndLWK+s9W+4CSNzsGpN5x6LlBs0jB3pc5ECx27+1KR6 olbe85n4cyAEE6stnB687L9dM68zhrh8pkFfr5zlEg+bnYaa/93NbECDt6QscIGZmbu0 FKbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature:arc-authentication-results; bh=mKROVNqNaY1u4L0xb+gy5mRj3fGpE9MaNOEhC4vqprc=; b=XuaUDLHVL7BYUzxkPt99E7g4m7M0H6B3AiFAu7OI+IQU0XGxS+WNUfZmvcnC+D0Txu on0XuGoRpaYAv3zLaFRE+OKDhsYO/vRQPk1esTmK6lJMUb1u0rxH/n3zlqyM8zy4f+5T eq3pviia+k4S3hUt19S8GURC4XmNS4ZediZkvpJ7UM1AP4HLY+uwyPmUhNyEU5AsoD1C hufI9C1iOUFBsH7TFuBOcqkWXUlUjccDyhiVTRPHXmqh+xzYQ9l95VGxibXEKdffw/vd d+hMtXmbElIt8MoA0pDNF/WpnSgVpoKJMZ3nb1/CjwBatHatTOA3JU4hzA7wB7hOMsbT blnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@anarazel.de header.s=fm1 header.b=kEkRPjSD; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=X9ES/yfu; 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 n6-v6si12540893pla.12.2018.04.23.13.58.46; Mon, 23 Apr 2018 13:59:02 -0700 (PDT) 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; dkim=pass header.i=@anarazel.de header.s=fm1 header.b=kEkRPjSD; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=X9ES/yfu; 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 S932336AbeDWU5f (ORCPT + 99 others); Mon, 23 Apr 2018 16:57:35 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:35013 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932163AbeDWU5c (ORCPT ); Mon, 23 Apr 2018 16:57:32 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id CC8E52113A; Mon, 23 Apr 2018 16:57:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 23 Apr 2018 16:57:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=mKROVNqNaY1u4L0xb+gy5mRj3fGpE9MaNOEhC4vqprc=; b=kEkRPjSD 9XQUyImH8xyHDrmKLNzELezXjPLQHyzAQu7K8wWwFdWEVy79x550ojAQB96gik8v T81n1Qd4k8a+JBgaUedwiFSmkLhVm5NOqhy3YCiVgYuRObx7oA+cMPxR2pakox50 618EGVddaDymNo9Z8s+CmuoIRIPPyM54d67lGsmIRbdX8yaTd1bFlniXKe6JALX5 knqiYaDXlP2HTtyIPMG8CLLDmMHGG6WEb6fgeiFYQsUFvNpXZCSDea0SOvDxkMDn rUJFAW91w/wFq8qZSFXo+Xb206tYKcDfcC6bSuk9iFxmHZckPgLo5TA1tLK8aCPa BNg8y//n7r/njg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=mKROVNqNaY1u4L0xb+gy5mRj3fGpE 9MaNOEhC4vqprc=; b=X9ES/yfuIHQiib8TLFXTACIZBr/K5hSvIB5lz3TC9RkkN ZWfOMYkQEGb2VxctDQmfqMpjaWf45Ufor98nPqqKMKLqr98CkY9LQ6fTtkL4u6zW I9z5QP6AeGwAs+XfYa+5F6elw9dgID4XlF5trS3gtAfhmVytQzxuBmDnJJN5agEv XwWvmXvmQQO+NaaGtbr89YtdCoyehcdNA1+g7QgBmlvqRXwNkqJ3u1v2RnEGqF9f nLh9VUznozvye67LJSOvoPwqvMFVmcYe9Vb2RIP9NBd0iBboMhTcXNJKRQgq49R6 Uo5WF+6zYjGotWx9/56bldtDNVySW81hS0MoBEdww== X-ME-Sender: Received: from intern.anarazel.de (unknown [198.233.165.212]) by mail.messagingengine.com (Postfix) with ESMTPA id 6471BE47F2; Mon, 23 Apr 2018 16:57:31 -0400 (EDT) Date: Mon, 23 Apr 2018 13:57:30 -0700 From: Andres Freund To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, Jeff Layton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Always report a writeback error once Message-ID: <20180423205730.34wvykqhefbkrtfw@alap3.anarazel.de> References: <20180423204208.GG13383@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180423204208.GG13383@bombadil.infradead.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2018-04-23 13:42:08 -0700, Matthew Wilcox wrote: > The errseq_t infrastructure assumes that errors which occurred before > the file descriptor was opened are of no interest to the application. > This turns out to be a regression for some applications, notably Postgres. > > Before errseq_t, a writeback error would be reported exactly once (as > long as the inode remained in memory), so Postgres could open a file, > call fsync() and find out whether there had been a writeback error on > that file from another process. > > This patch restores that behaviour by reporting errors to file descriptors > which are opened after the error occurred, but before it was reported > to any file descriptor. > > Cc: stable@vger.kernel.org > Fixes: 5660e13d2fd6 ("fs: new infrastructure for writeback error handling and reporting") > Signed-off-by: Matthew Wilcox > > diff --git a/lib/errseq.c b/lib/errseq.c > index df782418b333..093f1fba4ee0 100644 > --- a/lib/errseq.c > +++ b/lib/errseq.c > @@ -119,19 +119,11 @@ EXPORT_SYMBOL(errseq_set); > errseq_t errseq_sample(errseq_t *eseq) > { There's a comment above this: * * This function allows callers to sample an errseq_t value, marking it as * "seen" if required. > errseq_t old = READ_ONCE(*eseq); > - errseq_t new = old; > > - /* > - * For the common case of no errors ever having been set, we can skip > - * marking the SEEN bit. Once an error has been set, the value will > - * never go back to zero. > - */ > - if (old != 0) { > - new |= ERRSEQ_SEEN; > - if (old != new) > - cmpxchg(eseq, old, new); > - } > - return new; Which seems not to be true anymore after this hunk. > + /* If nobody has seen this error yet, then we can be the first. */ > + if (!(old & ERRSEQ_SEEN)) > + old = 0; > + return old; > } > EXPORT_SYMBOL(errseq_sample); I've never really looked at this code in any depth before, but won't this potentially lead to the same error being reported on multiple FDs? Imagine two fds (potentially in different processes) getting the 0 returned by errseq_sample() because it's not ERRSEQ_SEEN. Afaict file_check_and_advance_wb_err() will return an error that's always unlike 0 in that case, and thus the error will returned on both fds? I'm personally perfectly fine with that, but it's not necessarily what's described as desired in your email?. Greetings, Andres Freund