From patchwork Fri Mar 17 10:51:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vivek Trivedi X-Patchwork-Id: 9630329 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 4F79860132 for ; Fri, 17 Mar 2017 10:54:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3F9E7286A2 for ; Fri, 17 Mar 2017 10:54:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 342F22869B; Fri, 17 Mar 2017 10:54:44 +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=ham 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 780AE2869B for ; Fri, 17 Mar 2017 10:54:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751074AbdCQKy2 (ORCPT ); Fri, 17 Mar 2017 06:54:28 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:51068 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbdCQKy1 (ORCPT ); Fri, 17 Mar 2017 06:54:27 -0400 Received: from epcas2p4.samsung.com (unknown [182.195.41.56]) by mailout4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OMY00MO1GVTSM70@mailout4.samsung.com> for linux-fsdevel@vger.kernel.org; Fri, 17 Mar 2017 19:52:41 +0900 (KST) Received: from epsmges5p5.samsung.com (unknown [182.195.40.77]) by epcas2p4.samsung.com (KnoxPortal) with ESMTP id 20170317105240epcas2p4a82d719dc496ee881aee13f09defaadf~speCYAMQc3050930509epcas2p4s; Fri, 17 Mar 2017 10:52:40 +0000 (GMT) Received: from epcas5p3.samsung.com ( [182.195.41.41]) by epsmges5p5.samsung.com (EPCPMTA) with SMTP id 40.87.04904.8FFBBC85; Fri, 17 Mar 2017 19:52:40 +0900 (KST) Received: from epsmtrp2.samsung.com (unknown [182.195.40.14]) by epcas5p2.samsung.com (KnoxPortal) with ESMTPA id 20170317105240epcas5p24023b102f41ddfbb6dc2c276645daf64~speCEZjW12115021150epcas5p29; Fri, 17 Mar 2017 10:52:40 +0000 (GMT) Received: from epsmgmsp1.samsung.com (unknown [182.195.42.97]) by epsmtrp2.samsung.com (KnoxPortal) with ESMTP id 20170317105240epsmtrp200737395b799ce78f019ed1afcf6aa69~speCDWQiN2616626166epsmtrp2c; Fri, 17 Mar 2017 10:52:40 +0000 (GMT) X-AuditID: b6c32a59-f79736d000001328-76-58cbbff856fc Received: from epsmtip2.samsung.com ( [182.195.34.31]) by epsmgmsp1.samsung.com (Symantec Messaging Gateway) with SMTP id 8E.B8.30552.ADFBBC85; Fri, 17 Mar 2017 19:52:10 +0900 (KST) Received: from localhost.localdomain (unknown [107.108.92.210]) by epsmtip2.samsung.com (KnoxPortal) with ESMTPA id 20170317105238epsmtip276d63969be5cc313cc2f2e70629f9697~speAg53fV0149101491epsmtip2d; Fri, 17 Mar 2017 10:52:38 +0000 (GMT) From: Vivek Trivedi To: viro@zeniv.linux.org.uk, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Cc: a.sahrawat@samsung.com, pankaj.m@samsung.com, Vivek Trivedi Subject: [PATCH v2] fs: avoid iterate_supers to trigger call for sync on filesystem during mount Date: Fri, 17 Mar 2017 16:21:52 +0530 Message-id: <1489747912-49080-1-git-send-email-t.vivek@samsung.com> X-Mailer: git-send-email 1.9.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFKsWRmVeSWpSXmKPExsWy7bCmpu6P/acjDM480LW4uDvVYvb0ZiaL PXtPslhc3jWHzeLem61MFi/7NrJZnP97nNWB3aNvyypGjzMLjrB7fN4k57HpyVumAJaoVJuM 1MSU1CKF1Lzk/JTMvHRbJe/geOd4UzMDQ11DSwtzJYW8xNxUWyUXnwBdt8wcoAOUFMoSc0qB QgGJxcVK+nY2RfmlJakKGfnFJbZK0YaGRnqGBuZ6RkZGeiamsVZGpkAlCakZWw8eYi04J15x f8N2xgbGI0JdjJwcEgImEg/Xz2eCsMUkLtxbz9bFyMUhJLCUUWLPt6WMEM4nRomt8ztZ4JxT jdOYYdpffN/NDpHYySjxoWc/E4TzhVHi49yrYIPZBDQllnVcYQGxRQQyJOYfns8IYjMLhEss +j+ZFcQWFkiS6Gq7DFbDIqAq8WHtLDCbV8BZ4uuzd4wQ2+QkTh4DqecCshvZJK40rYQ6w0Vi x5wpbBC2sMSr41vYIWwpic/v9rJBNExmlJg46QM7hLOeUWLp1QdQ3fYSD24cBUpwAJ2kKbF+ lz5E2FZi+dolTCBhCQE+iRtvBSGO5pPo/f0EGmKKEgv3TmGFKOGV6GiDBqqHRNeOXywQtqPE trm9YKcJCcRKXH9+hHUCo/wshF0LGBlXMYqlFhTnpqcWmxaY6hUn5haX5qXrJefnbmIEpzOt yB2MV2YGHWIU4GBU4uE90HI6Qog1say4MvcQowQHs5IIb+QcoBBvSmJlVWpRfnxRaU5q8SFG U2BITmSWEk3OB6bavJJ4QxMzQxMjS2NTM3MDCyVx3iiDiRFCAumJJanZqakFqUUwfUwcnFIN jE0MWwVM5qfn/uGpjT+1/vqBZR/aZOT5G22+XCz/01JTuSPsJ2+FW8Ol8mvy4hv2uk24e1rm z7U61VOLj4qqfJhl05/ksIAlvExnX8eVPQ7HN3N4sjIciJo7wU9G05Xn/0mfYypRh9O5v8p/ SE4JbewQDPPo93qYuOzzlWyv8tU6fr/3TFG7pMRSnJFoqMVcVJwIANuGDIR9AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42LZdlhJXvfW/tMRBrd3sltc3J1qMXt6M5PF nr0nWSwu75rDZnHvzVYmi5d9G9kszv89zurA7tG3ZRWjx5kFR9g9Pm+S89j05C1TAEsUl01K ak5mWWqRvl0CV8bWg4dYC86JV9zfsJ2xgfGIUBcjJ4eEgInEi++72SFsMYkL99azdTFycQgJ bGeUONzSxgiRUJaY+eAUlC0ssfLfc3aIok+MEg3X/rKCJNgENCWWdVxh6WLk4BARyJHYc0sD JMwsEClx4eoEsAXCAgkST+e9YgKxWQRUJT6sncUCYvMKOEt8ffYOar6cxMljk1knMPIuYGRY xSiaWlCcm55bXGCoV5yYW1yal66XnJ+7iREcSFqJOxjXzQg/xCjAwajEw+sgcjpCiDWxrLgy 9xCjBAezkghv5BygEG9KYmVValF+fFFpTmrxIUZpDhYlcd5b1RsihATSE0tSs1NTC1KLYLJM HJxSDYwGK0Ti872qTzD9fNmtI7iI61zONPsI2+/h76+eaXbfe1jpHNf2/xVPMsOOC0Zb999Y HVa7V/Su7du1rsIqb0P3lF3rdNigecoxkN2/vt+9b7H7l+lrXzDvvvL2ye7uffsZpdNTFjsJ HLrYuy1uprV/l7f9w443yZ+qn2q3PAspf8VurqU18agSS3FGoqEWc1FxIgBnbmbEIAIAAA== X-CMS-MailID: 20170317105240epcas5p24023b102f41ddfbb6dc2c276645daf64 X-Msg-Generator: CA X-Sender-IP: 182.195.40.14 X-Local-Sender: =?UTF-8?B?VklWRUsgVFJJVkVESRtTUkktRGVsaGktUGxhdGZvcm0gUy9X?= =?UTF-8?B?IDEgVGVhbRvsgrzshLHsoITsnpAbU2VuaW9yIENoaWVmIEVuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?VklWRUsgVFJJVkVESRtTUkktRGVsaGktUGxhdGZvcm0gUy9X?= =?UTF-8?B?IDEgVGVhbRtTYW1zdW5nwqBFbGVjdHJvbmljcxtTZW5pb3IgQ2hpZWYgRW5n?= =?UTF-8?B?aW5lZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG1NXQUhRG0MxMElEMDJJRDAyODExNQ==?= Content-type: text/plain; charset=utf-8 X-MTR: 20170317105240epcas5p24023b102f41ddfbb6dc2c276645daf64 X-EPHeader: CA CMS-TYPE: 105P DLP-Filter: Pass X-CFilter-Loop: Reflected X-Auth-Email: t.vivek@samsung.com X-HopCount: 7 X-CMS-RootMailID: 20170317105240epcas5p24023b102f41ddfbb6dc2c276645daf64 X-RootMTR: 20170317105240epcas5p24023b102f41ddfbb6dc2c276645daf64 References: Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP It has been observed that apps may block in sys_sync for long time if there is parallel mount request for large size storage block device in a loaded environment. For example, sys_sync is reported to be hunged when a large size disk (e.g. 4TB/8TB disks) is connected. sys_mount may take time for reading large amount of metedata - free space accounting by reading bitmap during mount. The larger the volume, the larger the size of the bitmaps read during mount. During mount operation s_umount lock is taken by sys_mount. The lock is not released till the mount is completed. The sync() process keeps on waiting till s_umount is relased by sys_mount. Scenario: Process1 Process2 sys_sync() sys_mount() iterate_supers do_mount() ... vfs_kern_mount() ... mount_fs() (Filesystem_mount) ... mount_bdev() ... sget() ... alloc_super() ... down_write_nested(&s->s_umount, ... SINGLE_DEPTH_NESTING); ... => LOCK HELD by MOUNT ... ... ... ... down_read(&sb->s_umount); ... => WAITING FOR LOCK ... ... ... ... fill_super() ... => time TAKING (per filesystem) ... up_write(&sb->s_umount); ... => LOCK RELEASE by mount process ... ... => STUCK TILL MOUNT is completed Since, the superblock gets added to the list during the mount path alloc_super, so the 'sb' is visible in the s_list. But the behaviour of waiting to sync() a filesystem which is not active yet, seems ambigous here. To avoid this issue, may be we should consider about having to check only the ACTIVE filesystem for doing operations from the superblock list. Once mount i.e. fill_super is completed, MS_BORN is set on the superblock flags. If MS_BORN flag is not set on superblock flags, it means mount is not completed yet, there is no point in waiting for sys_sync in that superblock. Signed-off-by: Vivek Trivedi Reviewed-by: Amit Sahrawat Reviewed-by: Jan Kara --- Changes in v2: - it is more consistent to use MS_BORN instead of MS_ACTIVE as it is already used in iterate_supers(), just under s_umount - apply same change in iterate_supers_type() to keep them consistent fs/super.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/super.c b/fs/super.c index b8b6a08..d9b96d6 100644 --- a/fs/super.c +++ b/fs/super.c @@ -587,6 +587,10 @@ void iterate_supers(void (*f)(struct super_block *, void *), void *arg) list_for_each_entry(sb, &super_blocks, s_list) { if (hlist_unhashed(&sb->s_instances)) continue; + + if (!(sb->s_flags & MS_BORN)) + continue; + sb->s_count++; spin_unlock(&sb_lock); @@ -621,6 +625,9 @@ void iterate_supers_type(struct file_system_type *type, spin_lock(&sb_lock); hlist_for_each_entry(sb, &type->fs_supers, s_instances) { + if (!(sb->s_flags & MS_BORN)) + continue; + sb->s_count++; spin_unlock(&sb_lock);