From patchwork Mon Jan 8 19:15:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 10150375 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1E1D6602CA for ; Mon, 8 Jan 2018 19:15:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 25BB72623C for ; Mon, 8 Jan 2018 19:15:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1A33A28543; Mon, 8 Jan 2018 19:15:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B981528543 for ; Mon, 8 Jan 2018 19:15:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932371AbeAHTPh (ORCPT ); Mon, 8 Jan 2018 14:15:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:48678 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755658AbeAHTPe (ORCPT ); Mon, 8 Jan 2018 14:15:34 -0500 Received: from tleilax.poochiereds.net (cpe-71-70-156-158.nc.res.rr.com [71.70.156.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E90E221726; Mon, 8 Jan 2018 19:15:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E90E221726 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jlayton@kernel.org Message-ID: <1515438929.3486.48.camel@kernel.org> Subject: Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently From: Jeff Layton To: Krzysztof Kozlowski Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-nfs@vger.kernel.org, bfields@fieldses.org, neilb@suse.de, jack@suse.de, linux-ext4@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, linux-xfs@vger.kernel.org, darrick.wong@oracle.com, david@fromorbit.com, linux-btrfs@vger.kernel.org, clm@fb.com, jbacik@fb.com, dsterba@suse.com, linux-integrity@vger.kernel.org, zohar@linux.vnet.ibm.com, dmitry.kasatkin@gmail.com, linux-afs@lists.infradead.org, dhowells@redhat.com, jaltman@auristor.com, linux-samsung-soc@vger.kernel.org, Marek Szyprowski , =?UTF-8?Q?Bart=C5=82omiej_?= =?UTF-8?Q?=C5=BBo=C5=82nierkiewicz?= , Sylwester Nawrocki Date: Mon, 08 Jan 2018 14:15:29 -0500 In-Reply-To: <20180108183353.emiwsd4aic4gmytr@kozik-lap> References: <20171222120556.7435-1-jlayton@kernel.org> <20171222120556.7435-20-jlayton@kernel.org> <1515416208.3486.14.camel@kernel.org> <1515418164.3486.18.camel@kernel.org> <20180108172928.aqndozcpljb73uj6@kozik-lap> <1515434419.3486.41.camel@kernel.org> <20180108183353.emiwsd4aic4gmytr@kozik-lap> X-Mailer: Evolution 3.26.3 (3.26.3-1.fc27) Mime-Version: 1.0 Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote: > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote: > > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote: > > (...) > > > > > Ok, thanks. If you're seeing hangs then that might imply that we have > > > > some sort of excessive looping going on in the cmpxchg loops. > > > > > > > > Could you apply the patch below and let me know if it causes either of > > > > the warnings to pop? That might at least point us in the right > > > > direction: > > > > > > No new warnings with attached patch (except existing already lockdep: > > > "INFO: trying to register non-static key."). > > > > > > > Yeah, I saw that in the original logs and it looks unrelated (and > > harmless). > > > > > Systemd timeouts on mounting /home but after entering rescue shell there > > > is no problem running mount /home: > > > Give root password for maintenance > > > (or press Control-D to continue): > > > root@odroidxu3:~# mount /home > > > [ 220.659331] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null) > > > > > > > Ok, thanks for testing it. So I guess we can probably rule out excessive > > looping in those functions as the issue. > > > > To make sure I understand the problem: When systemd tries to do the > > initial mount of /home (which is an ext4 filesystem), it hangs. But once > > it drops to the shell, it works, if you do the mount by hand. > > > > Is that correct? > > Yes, although it also timeouts on setting up /dev/ttySAC2 (serial > console). > > > If so, then is it possible to trigger sysrq commands during the hanging > > mount attempt? Maybe you could use e.g. sysrq-l, sysrq-w, etc. to > > determine what it's blocking on? (trimming the output) Thanks. I don't really see anything obvious in that info, unfortunately. What we really need to do is find the systemd task performing the mount, and see what it's doing. We do have one questionable bug in the NFS changes though. Does this patch help at all? -------------------------------8<--------------------------------- SQUASH: nfs: fix i_version increment when adding a request NFS treats this value as an opaque value with no flag, so we must increment it as such instead of using inode_inc_iversion. Signed-off-by: Jeff Layton --- fs/nfs/write.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/write.c b/fs/nfs/write.c index a03fbac1f88c..48837b6250e9 100644 --- a/fs/nfs/write.c +++ b/fs/nfs/write.c @@ -755,7 +755,7 @@ static void nfs_inode_add_request(struct inode *inode, struct nfs_page *req) spin_lock(&mapping->private_lock); if (!nfs_have_writebacks(inode) && NFS_PROTO(inode)->have_delegation(inode, FMODE_WRITE)) - inode_inc_iversion(inode); + atomic64_inc(&inode->i_version); if (likely(!PageSwapCache(req->wb_page))) { set_bit(PG_MAPPED, &req->wb_flags); SetPagePrivate(req->wb_page);