From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754119AbdBGMEb (ORCPT ); Tue, 7 Feb 2017 07:04:31 -0500 Received: from mailout4.samsung.com ([203.254.224.34]:54623 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753284AbdBGME0 (ORCPT ); Tue, 7 Feb 2017 07:04:26 -0500 X-AuditID: b6c32a36-f79dd6d000001a4f-98-5899b7c73709 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] fs: avoid iterate_supers to trigger call for sync on filesystem during mount Date: Tue, 07 Feb 2017 17:35:33 +0530 Message-id: <1486469133-34008-1-git-send-email-t.vivek@samsung.com> X-Mailer: git-send-email 1.9.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsWy7bCmge7x7TMjDFq/iVpc3J1qsWfvSRaL y7vmsFnce7OVyeJl30Y2i/N/j7M6sHn0bVnF6PF5k5zHpidvmQKYo1JtMlITU1KLFFLzkvNT MvPSbZW8g+Od403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4DWKimUJeaUAoUCEouLlfTtbIry S0tSFTLyi0tslaINDY30DA3M9YyMjPRMTGOtjEyBShJSMy7uvM5UMEOiYsPpr+wNjKf4uhg5 OSQETCRWnZ/BAmGLSVy4t56ti5GLQ0hgB6PErN+PmSCcdiaJ89tmsMF03Li4Bioxh1Hi28R2 RpCEkMBPRolP02pAbDYBTYllHVfAxooIREl0brzBDmIzC4RLLPo/mbWLkYNDWCBe4vJKNZAw i4CqROuDDiYQm1fAWeL10UaoXXISJ4+BlHMB2UfYJJYsXckO0ishICux6QAzRI2LxJ37y6Hq hSVeHd/CDmFLS6z6d4sJoncyo8TESR/YIZz1jBJLrz6A6raXeHDjKNRxfBLvvvawQizgleho E4Io8ZBoPXQNaqijxI/NB8FKhARiJU51l0xglF7AyLCKUSy1oDg3PbXYsMBIrzgxt7g0L10v OT93EyM4fWiZ7WBcdM7nEKMAB6MSD29Gx4wIIdbEsuLK3EOMEhzMSiK8AVtmRgjxpiRWVqUW 5ccXleakFh9iNAUGzURmKdHkfGBqyyuJNzQxMzQxMjG0NDAyM1AS52U1mBghJJCeWJKanZpa kFoE08fEwSnVwBjJXaRtVP5zkep54yC2J7l3t1v2p7erOJy9vcltw7QA9tln4l61n3X4qyzz yaZ6ee6LttdbZyuZzFc68PW3erxOXPW2zTpLjuxTZHgenN+yxeTYuRSfNzXOEw7+neW34apT sDf/5cagp9OjbNW8N6jNN4i7qmxgLP5gUfuyE0JbrWQ2O/LvPaTEUpyRaKjFXFScCACFgHvr NQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsVy+t9jQd1j22dGGPybpGpxcXeqxZ69J1ks Lu+aw2Zx781WJouXfRvZLM7/Pc7qwObRt2UVo8fnTXIem568ZQpgjnKzyUhNTEktUkjNS85P ycxLt1UKDXHTtVBSyEvMTbVVitD1DQlSUihLzCkF8owM0ICDc4B7sJK+XYJbxsWd15kKZkhU bDj9lb2B8RRfFyMnh4SAicSNi2uYIGwxiQv31rN1MXJxCAnMYpR4+fohlPOTUeLHgt1sIFVs ApoSyzqusIDYIgJREn13P7KD2MwC4RIfn7UA1XBwCAvES1xeqQYSZhFQlWh90AG2gFfAWeL1 0UY2iGVyEiePTWadwMi9gJFhFaNEakFyQXFSeq5hXmq5XnFibnFpXrpecn7uJkZwCD6T2sF4 cJf7IUYBDkYlHt6MjhkRQqyJZcWVuYcYJTiYlUR4A7bMjBDiTUmsrEotyo8vKs1JLT7EaAp0 wERmKdHkfGB85JXEG5qYm5gbG1iYW1qaGCmJ8zbOfhYuJJCeWJKanZpakFoE08fEwSnVwOj1 THR56fNZ8qI7ZprO1ZrhttS8bU74gkuKm5xfajm8qyoPnfbMMqrGcY9QIeeMo4sfPNB/+y4u /Mb9S5f8bVebG7JEzp388OjfdYtuhnccK2tyXt+jb92/UbriWds/z1tN4rcW5K2YdtIlc6pc 3ZM1/62ZmgwcXz6L+i3zusQ+63LV6Ui31ZOUWIozEg21mIuKEwFJiCOPVwIAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170207120422epcas1p18cb1bd5dbd0bf2dc3852105d05e63f10 X-Msg-Generator: CA X-Sender-IP: 203.254.230.26 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: 101P DLP-Filter: Pass X-CFilter-Loop: Reflected X-HopCount: 7 X-CMS-RootMailID: 20170207120422epcas1p18cb1bd5dbd0bf2dc3852105d05e63f10 X-RootMTR: 20170207120422epcas1p18cb1bd5dbd0bf2dc3852105d05e63f10 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 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. 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..ef3f57c 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_root && !(sb->s_flags & MS_ACTIVE)) + continue; + sb->s_count++; spin_unlock(&sb_lock); -- 1.9.1