Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1133377pxk; Fri, 2 Oct 2020 01:41:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZIVrRwnimiEDs0lTnGTHh3lw9ko1W27Iqys2v6jFN3cv8uVftv6NWl5iKF0w+B5u7oPK2 X-Received: by 2002:a50:ce4e:: with SMTP id k14mr1157786edj.177.1601628078353; Fri, 02 Oct 2020 01:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601628078; cv=none; d=google.com; s=arc-20160816; b=nbN4Hf9OS6azIu/ftB10FrTCg1ap/UBZT8N7n73ywXM6YWJ/CG76z8g4DjxsN/4t/9 YsO+6YzTbbp5bIcq/Nk36c1BVHIe5OdKbNjmn6W9gRbXOLoeZssXqnbElox1Rqe0Zl8w 7752DQSvsGUqIENiJwPqd5qGSKXlrk3gTT3JSyytt/YdSnuqG8jp1yp73kLyOfPC1/cd w/1mpDcNwGZilzWXnkzb6s7tLU4XYoKQ9VfskA8ACbc5M/uk06bIyFKFp8bR0NSf3VuG UV2Ncqcv7TnKxqUq4E6sNQv3Sx54Abbmdo0ZMyHbmxDofM+AwB2MvYqaKI1dW+zRLfTm LSDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ZNgZf++iOx4AvEXWiChdRcOlUas1o96e6DGsYEcOZz4=; b=A6piPVkKOdDR1Ib/PumxVV8vDZhe9U5eSOx0jJb578NTdJdANzGeSEe67yYpBjbPK2 d0D9ceJ55jYTGm7flpxITPaBTWXfcPer+WgRjhu0lhAlfE59/ihaP9VZ7SuiGS+eWOp6 wdh0F0P3isyGWi8AKjpOrSDs78dSr18rIAm/nrozKRaqY/PjD9xNzQq0sGFXo8eR++Mf P3KvcRaHrUxDFh4IoYzKD39JchMP2fH1vzcJXXU4Qn8ije6vPenkTyjnQ40bC700XiPN S0aAJLQQnbfX8mcG1j4iU6w97LlELgYu9oxJYOAsaWzXmwVwAhGhgKQZE1a64Mm7onPo 0HDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u19si522360eds.502.2020.10.02.01.40.45; Fri, 02 Oct 2020 01:41:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726499AbgJBIjf (ORCPT + 99 others); Fri, 2 Oct 2020 04:39:35 -0400 Received: from mx2.suse.de ([195.135.220.15]:60794 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725961AbgJBIjb (ORCPT ); Fri, 2 Oct 2020 04:39:31 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DD2A9AC82; Fri, 2 Oct 2020 08:39:29 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 91BE51E12EF; Fri, 2 Oct 2020 10:39:29 +0200 (CEST) Date: Fri, 2 Oct 2020 10:39:29 +0200 From: Jan Kara To: Mauricio Faria de Oliveira Cc: Jan Kara , Andreas Dilger , linux-ext4@vger.kernel.org, dann frazier , Ted Tso Subject: Re: [RFC PATCH v4 0/4] ext4/jbd2: data=journal: write-protect pages on transaction commit Message-ID: <20201002083929.GB17963@quack2.suse.cz> References: <20200928194103.244692-1-mfo@canonical.com> <20200929113727.GK10896@quack2.suse.cz> <20201001073433.GB17860@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu 01-10-20 09:46:32, Mauricio Faria de Oliveira wrote: > On Thu, Oct 1, 2020 at 4:34 AM Jan Kara wrote: > > On Wed 30-09-20 19:59:44, Mauricio Faria de Oliveira wrote: > > > 3) Now, the mixed-feelings news. > > > > > > The synthetic test-case/patches I had written clearly show that the > > > patchset works: > > > - In the original kernel, userspace can write to buffers during > > > commit; and it moves on. > > > - In the patched kernel, userspace cannot write to buffers during > > > commit; it blocks. > > > > > > However, the heavy-hammer testing with 'stress-ng --mmap 4xNCPUs --mmap-file' > > > then crashing the kernel via sysrq-trigger, and trying to mount the > > > filesystem again, > > > sometimes still can find invalid checksums, thus journal recovery/mount fails. > > > > > > [ 98.194809] JBD2: Invalid checksum recovering data block 109704 in log > > > [ 98.201853] JBD2: Invalid checksum recovering data block 69959 in log > > > [ 98.339859] JBD2: recovery failed > > > [ 98.340581] EXT4-fs (vdc): error loading journal > > > > > > So, despite the test exercising mmap() and the patchset being for mmap(), > > > apparently there is more happening that also needs changes. (Weird; but > > > I will try to debug that test-case behavior deeper, to find what's going on.) > > > > > > This patchset does address a problem, so should we move on with this one, > > > and as you mentioned, "that would be something for another patch series :)" ? > > > > Thanks for the really throughout testing! If you can debug where the > > problem is still lurking fast, then cool, we can still fix it in this patch > > series. If not, then I'm fine with just pushing what we have because > > conceptually that seems like a sane thing to do anyway and we can fix the > > remaining problem afterwards. > > Understood. I'll be able to look at this next week, which should be rc8 [1]. > Would it be good enough, timing wise, to send a non-RFC series with > what we have (this other issue fixed or not) by the end of next week? This is more a question for Ted as a maintainer (CCed) but end of next week is probably too late because Ted needs time to merge the patches in his tree, run his battery of tests, push changes to linux-next and let them simmer there for a while before sending them to Linus. So I'd say submit what you have on Monday / Tuesday and we can always add fixes on top as we find them. Honza -- Jan Kara SUSE Labs, CR