From patchwork Fri Apr 24 07:54:35 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 6266791 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id C0D95BF4A6 for ; Fri, 24 Apr 2015 07:54:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E661320266 for ; Fri, 24 Apr 2015 07:54:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EBC532026F for ; Fri, 24 Apr 2015 07:54:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755426AbbDXHyk (ORCPT ); Fri, 24 Apr 2015 03:54:40 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:34826 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755422AbbDXHyh (ORCPT ); Fri, 24 Apr 2015 03:54:37 -0400 Received: by widdi4 with SMTP id di4so12109863wid.0 for ; Fri, 24 Apr 2015 00:54:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=XbpC6Uvbia9JT+zc5m8tXKQ1X7F6So1CzbYL7RIUKFk=; b=Bp4SeU7FQ4WQHwRO+msdAiV2GuLVy06L95rtBWBj98ZCffpNcs1KaercDZ0xzsae5z EKAiPlnI5QIXkHfG2Hdw9zpiLXs9sgUzZaP1NNxuVhYhmFEKWwTo8lKeKLNq/0Lp3m2b ahgMJKRTbWO1rGWu7eC+Pu8x7Lm57/WYLbMxYJ0u4qsL6Yo9G/+LHOMRuCfM3vwI6XTZ KqTqkGbOp9qy7WQyZPmV0DW3h0xo1XkWYYaApjZhAm325ygEfZ1X35x0NnEJeCHbzC8/ p76auRD2cvPq4smEtWL/8/Qa2rRp8kjAvrVUvk02zNq+iCUKRdGlSBQ8DQUgzqDbXnuV yflQ== X-Gm-Message-State: ALoCoQm3Wk3xc6w/Nw3v9nSHcf0YQcPl5JwUnqVlPhh1eiqys94HcA7ChRBt98wi/+fEhFj2ZMXW MIME-Version: 1.0 X-Received: by 10.194.47.165 with SMTP id e5mr12981406wjn.128.1429862075550; Fri, 24 Apr 2015 00:54:35 -0700 (PDT) Received: by 10.28.100.214 with HTTP; Fri, 24 Apr 2015 00:54:35 -0700 (PDT) Date: Fri, 24 Apr 2015 10:54:35 +0300 Message-ID: Subject: [RFC][PATCH] sysrq: Emergency Remount R/O in reverse order From: Amir Goldstein To: viro@zeniv.linux.org.uk Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, "Theodore Ts'o" , Oren Laadan Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Al, This patch is very naive. The fact that it tries to change a behavior that pre-dates modern git history suggests that I may be missing something. I am quite sure that the change of behavior is beneficial to my use case which involves loop mounts on Android, hence uploaded for Android: https://android-review.googlesource.com/148047 I am not sure about the implications for other use cases, hence this RFC. Is there a reason to start remount from root fs, because later remounts may hang or take too long before some watchdog kicks in? Please enlighten me. Thanks, Amir. ---------- Forwarded message ---------- This change fixes a problem where reboot on Android panics the kernel almost every time when file systems are mounted over loop devices. Android reboot command does: - sync - echo u > /proc/sysrq-trigger - syscall_reboot The problem is with sysrq emergency remount R/O trying to remount-ro in wrong order. since /data is re-mounted ro before loop devices, loop device remount-ro fails to flush the journal and panics the kernel: EXT4-fs (loop0): Remounting filesystem read-only EXT4-fs (loop0): previous I/O error to superblock detected loop: Write error at byte offset 0, length 4096. Buffer I/O error on device loop0, logical block 0 lost page write due to I/O error on loop0 Kernel panic - not syncing: EXT4-fs panic from previous error The fix is quite simple. In do_emergency_remount(), use list_for_each_entry_reverse() on sb list instead of list_for_each_entry(). It makes a lot of sense to umount the file systems in reverse order in which they were added to sb list. Signed-off-by: Amir Goldstein Acked-by: Oren Laadan --- fs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/super.c b/fs/super.c index 2b7dc90..f1315e0 100644 --- a/fs/super.c +++ b/fs/super.c @@ -774,7 +774,7 @@ static void do_emergency_remount(struct work_struct *work) struct super_block *sb, *p = NULL; spin_lock(&sb_lock); - list_for_each_entry(sb, &super_blocks, s_list) { + list_for_each_entry_reverse(sb, &super_blocks, s_list) { if (hlist_unhashed(&sb->s_instances)) continue; sb->s_count++;