From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753719AbdBHL73 (ORCPT ); Wed, 8 Feb 2017 06:59:29 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:59824 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752160AbdBHL71 (ORCPT ); Wed, 8 Feb 2017 06:59:27 -0500 X-AuditID: b6c32a2e-f79656d0000012f2-41-589b07815ed9 From: Vivek Trivedi To: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Cc: a.sahrawat@samsung.com, pankaj.m@samsung.com, Vivek Trivedi Subject: [PATCH RESEND] fs: avoid iterate_supers to trigger call for sync on filesystem during mount Date: Wed, 08 Feb 2017 17:27:58 +0530 Message-id: <1486555078-10383-1-git-send-email-t.vivek@samsung.com> X-Mailer: git-send-email 1.9.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsWy7bCmum4j++wIg4tHeS0u7k612LP3JIvF 5V1z2CzuvdnKZPGybyObxfm/x1kd2Dz6tqxi9Pi8Sc5j05O3TAHMUak2GamJKalFCql5yfkp mXnptkrewfHO8aZmBoa6hpYW5koKeYm5qbZKLj4Bum6ZOUBrlRTKEnNKgUIBicXFSvp2NkX5 pSWpChn5xSW2StGGhkZ6hgbmekZGRnomprFWRqZAJQmpGVfer2QquChRsf3nIbYGxm98XYyc HBICJhKnT+9nhbDFJC7cW8/WxcjFISSwlFHi5YI37BBOO5PEkYNPWGA6Vn9+BpWYwyix4MZ6 JpCEkMBPRokzEzxBbDYBTYllHVfAGkQEoiQ6N95gB7GZBcIlFv2fDLZOWCBNYsaaM0A2BweL gKrEv+/mIGFeAWeJ01PuMEHskpM4eQyknAvIPsImsXjTF2aQegkBWYlNB5ghalwkbjxaDWUL S7w6voUdwpaW+Lv0FiNE72RGiYmTPrBDOOsZJZZefQDVYS/x4MZRqOP4JHp/P2GCWMAr0dEm BFHiIdH1/CgbhO0oMXlaIyPEv7ES0+61sk9glF7AyLCKUSy1oDg3PbXYtMBYrzgxt7g0L10v OT93EyM4gWjp7WD8t8D7EKMAB6MSD++NxFkRQqyJZcWVuYcYJTiYlUR457DMjhDiTUmsrEot yo8vKs1JLT7EaAoMmonMUqLJ+cDkllcSb2hiZmhiZGlsamZuYKEkzhtlMDFCSCA9sSQ1OzW1 ILUIpo+Jg1OqgZHnnt3BGw0vmRSmfFmmxtGh61Egtuvq4bkCq054H/zn9vGazw4ZubaANZ0a +6dszkrfe+FJAdCw29t281es9yn/M2/uuhgVeYeZG7NrxM2/3sqSnVa1SM9fr+WBkNWfaVdF GHYpOc81ED1TL1mgvSX0Z+3e5Wr2Ev2tMs9VAtYfTs9e2T/xrRJLcUaioRZzUXEiAOeDGPo2 AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsVy+t9jQd0G9tkRBpdblC0u7k612LP3JIvF 5V1z2CzuvdnKZPGybyObxfm/x1kd2Dz6tqxi9Pi8Sc5j05O3TAHMUW42GamJKalFCql5yfkp mXnptkqhIW66FkoKeYm5qbZKEbq+IUFKCmWJOaVAnpEBGnBwDnAPVtK3S3DLuPJ+JVPBRYmK 7T8PsTUwfuPrYuTkkBAwkVj9+Rk7hC0mceHeejYQW0hgFqPEoq0CXYxcQPZPRonn99cwgiTY BDQllnVcYQGxRQSiJPrufgRrZhYIl/j4rAWsWVggTWLGmjOsXYwcHCwCqhL/vpuDhHkFnCVO T7nDBLFLTuLkscmsExi5FzAyrGKUSC1ILihOSs81ykst1ytOzC0uzUvXS87P3cQIDsBn0jsY D+9yP8QowMGoxMNbETErQog1say4MvcQowQHs5II7xyW2RFCvCmJlVWpRfnxRaU5qcWHGE2B 9k9klhJNzgdGR15JvKGJuYm5sYGFuaWliZGSOG/j7GfhQgLpiSWp2ampBalFMH1MHJxSDYxO czxza2Q+qv6QlMuRidE/WPm6zDRd5pPGjbt/tqg+neT236ozcHVAUdjPZssNz6zFg06vapBf y3fgRs5L4YdPD7isV/1dOGvKX3V204W3MxiKdY74pU2UCX7+pbvZeu3zI37Xq44svb3Wbu1N 1y9HFb/8yG78OnGj0crEg2fCs4p6tX9v4PVSYinOSDTUYi4qTgQAEhRX1VYCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170208115648epcas5p23f74eab3a9fb73571f233f91625722d6 X-Msg-Generator: CA X-Sender-IP: 203.254.230.27 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==?= CMS-TYPE: 105P DLP-Filter: Pass X-CFilter-Loop: Reflected X-HopCount: 7 X-CMS-RootMailID: 20170208115648epcas5p23f74eab3a9fb73571f233f91625722d6 X-RootMTR: 20170208115648epcas5p23f74eab3a9fb73571f233f91625722d6 References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 (as per filesystem) . up_write(&sb->s_umount); => LOCK RELEASE by mount process . . STUCKED 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. 'sb' is valid and referencable as long as part of the s_list and MS_ACTIVE is set after successful mount and cleared during the umount path from generic_shutdown_super. --- Fixed a typo and updated the condition in iterate_supers. Signed-off-by: Vivek Trivedi Reviewed-by: Amit Sahrawat --- fs/super.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/super.c b/fs/super.c index b8b6a08..01711a4 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_ACTIVE)) + continue; + sb->s_count++; spin_unlock(&sb_lock); -- 1.9.1