mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-mmc@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: Regression in suspend to ram in 2.6.31-rc kernels
Date: Sun, 06 Sep 2009 02:22:27 +0900	[thread overview]
Message-ID: <87iqfx5mss.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <c4e36d110909040213t4d4258b4w3e2d4725e0b2a161@mail.gmail.com> (Zdenek Kabelac's message of "Fri, 4 Sep 2009 11:13:02 +0200")

Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:

> 2009/9/4 OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
>> Christoph Hellwig <hch@lst.de> writes:
>>
>>> Note that when you rever this patch on a current kernel you do actually
>>> get different behvaviour than when going back to before this commit.
>>>
>>> In 2.6.30 we called ->write_super in the various sync functions and
>>> then ->sync_fs, in 2.6.31-rc8 you would not call any syncing at all
>>> anymore.  I think this patch might just be a symptom for a situation
>>> where the suspend code causes a sync and the mmc driver can't handle
>>> it anymore.
>
> So - here is the console trace from suspend when I've added
> dump_stack() to the fat_sync_fs()   (and also added debug prints
> around each call in this function -so its obvious the function is
> actually left - but then it freezes later somewhere.)
>
> It's interesting that 3 calls to sync happens.

It seems

    1) sync() (probabry "sync" command)
    2) sync as part of suspend sequence
    3) sync_filesystem() by mmc remove event

I guess the root-cause of the problem would be 3). However, it would not
be easy to fix, at least, we would need to think about what we want to
do for it. So, to workaround it for now, I've made this patch.

Can you try whether this patch fixes this problem?

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>



Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 fs/fat/fat.h   |    2 +-
 fs/fat/inode.c |   14 +++++++++-----
 fs/fat/misc.c  |    8 +++++---
 3 files changed, 15 insertions(+), 9 deletions(-)

diff -puN fs/fat/inode.c~fat_sync_fs fs/fat/inode.c
--- linux-2.6/fs/fat/inode.c~fat_sync_fs	2009-09-03 21:24:03.000000000 +0900
+++ linux-2.6-hirofumi/fs/fat/inode.c	2009-09-06 02:07:07.000000000 +0900
@@ -451,12 +451,16 @@ static void fat_write_super(struct super
 
 static int fat_sync_fs(struct super_block *sb, int wait)
 {
-	lock_super(sb);
-	fat_clusters_flush(sb);
-	sb->s_dirt = 0;
-	unlock_super(sb);
+	int err = 0;
 
-	return 0;
+	if (sb->s_dirt) {
+		lock_super(sb);
+		sb->s_dirt = 0;
+		err = fat_clusters_flush(sb);
+		unlock_super(sb);
+	}
+
+	return err;
 }
 
 static void fat_put_super(struct super_block *sb)
diff -puN fs/fat/misc.c~fat_sync_fs fs/fat/misc.c
--- linux-2.6/fs/fat/misc.c~fat_sync_fs	2009-09-03 21:24:03.000000000 +0900
+++ linux-2.6-hirofumi/fs/fat/misc.c	2009-09-06 02:02:56.000000000 +0900
@@ -43,19 +43,19 @@ EXPORT_SYMBOL_GPL(fat_fs_error);
 
 /* Flushes the number of free clusters on FAT32 */
 /* XXX: Need to write one per FSINFO block.  Currently only writes 1 */
-void fat_clusters_flush(struct super_block *sb)
+int fat_clusters_flush(struct super_block *sb)
 {
 	struct msdos_sb_info *sbi = MSDOS_SB(sb);
 	struct buffer_head *bh;
 	struct fat_boot_fsinfo *fsinfo;
 
 	if (sbi->fat_bits != 32)
-		return;
+		return 0;
 
 	bh = sb_bread(sb, sbi->fsinfo_sector);
 	if (bh == NULL) {
 		printk(KERN_ERR "FAT: bread failed in fat_clusters_flush\n");
-		return;
+		return -EIO;
 	}
 
 	fsinfo = (struct fat_boot_fsinfo *)bh->b_data;
@@ -74,6 +74,8 @@ void fat_clusters_flush(struct super_blo
 		mark_buffer_dirty(bh);
 	}
 	brelse(bh);
+
+	return 0;
 }
 
 /*
diff -puN fs/fat/fat.h~fat_sync_fs fs/fat/fat.h
--- linux-2.6/fs/fat/fat.h~fat_sync_fs	2009-09-03 21:24:03.000000000 +0900
+++ linux-2.6-hirofumi/fs/fat/fat.h	2009-09-06 02:02:56.000000000 +0900
@@ -323,7 +323,7 @@ extern int fat_flush_inodes(struct super
 /* fat/misc.c */
 extern void fat_fs_error(struct super_block *s, const char *fmt, ...)
 	__attribute__ ((format (printf, 2, 3))) __cold;
-extern void fat_clusters_flush(struct super_block *sb);
+extern int fat_clusters_flush(struct super_block *sb);
 extern int fat_chain_add(struct inode *inode, int new_dclus, int nr_cluster);
 extern void fat_time_fat2unix(struct msdos_sb_info *sbi, struct timespec *ts,
 			      __le16 __time, __le16 __date, u8 time_cs);
_

  reply	other threads:[~2009-09-05 17:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-31 11:51 Zdenek Kabelac
2009-08-31 19:19 ` Rafael J. Wysocki
2009-09-01  9:34   ` Zdenek Kabelac
2009-09-03 22:29     ` Zdenek Kabelac
2009-09-03 23:23       ` Christoph Hellwig
2009-09-04  0:47         ` OGAWA Hirofumi
2009-09-04  9:13           ` Zdenek Kabelac
2009-09-05 17:22             ` OGAWA Hirofumi [this message]
2009-09-05 19:53               ` Zdenek Kabelac
2009-09-05 22:42                 ` OGAWA Hirofumi
2009-09-08  8:10                   ` Zdenek Kabelac
2009-09-09 13:15                     ` OGAWA Hirofumi
2009-09-07 12:51               ` Pavel Machek
2009-09-09 13:21                 ` OGAWA Hirofumi
2009-09-10 19:23                   ` Pavel Machek
2009-09-11  6:39                     ` OGAWA Hirofumi
2009-09-11 20:09                       ` Pavel Machek
2009-09-11 21:14                         ` Zdenek Kabelac
2009-09-11 21:32                           ` Pavel Machek
2009-09-11 21:45                             ` Zdenek Kabelac
2009-09-11 21:51                               ` Pavel Machek
2009-09-11 22:22                                 ` Rafael J. Wysocki
2009-09-14 20:05                                 ` Pierre Ossman
2009-09-14 20:25                                   ` Pavel Machek
2009-09-11 22:29                               ` Chris Ball
2009-09-11 22:36                                 ` Rafael J. Wysocki
2009-09-14  8:39                                   ` Zdenek Kabelac
2009-09-14 19:17                                     ` Rafael J. Wysocki
2009-09-14 20:27                                     ` Pavel Machek
2009-09-18 11:15                                   ` OGAWA Hirofumi
2009-09-18 21:39                                     ` Rafael J. Wysocki
2009-09-11 22:22                           ` Chris Ball
2009-09-11 22:04                       ` Rafael J. Wysocki
2009-09-11 22:21                         ` Pavel Machek
2009-09-11 22:32                           ` Rafael J. Wysocki
2009-09-08 19:06           ` Christoph Hellwig
2009-09-08 19:48             ` Rafael J. Wysocki
2009-09-09 13:52             ` OGAWA Hirofumi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iqfx5mss.fsf@devron.myhome.or.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zdenek.kabelac@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®