headers
Hugh Dickins | 1 May 2011 04:35
Picon
Favicon

[PATCH] mmotm: fix hang at startup

Yesterday's mmotm hangs at startup, and with lockdep it reports:
BUG: spinlock recursion on CPU#1, blkid/284 - with bdi_lock_two()
called from bdev_inode_switch_bdi() in the backtrace.  It appears
that this function is sometimes called with new the same as old.

Signed-off-by: Hugh Dickins <hughd <at> google.com>
---
Fix to
writeback-split-inode_wb_list_lock-into-bdi_writebacklist_lock.patch

 fs/block_dev.c |    2 ++
 1 file changed, 2 insertions(+)

--- 2.6.39-rc5-mm1/fs/block_dev.c	2011-04-29 18:20:09.183314733 -0700
+++ linux/fs/block_dev.c	2011-04-30 17:55:45.718785263 -0700
 <at>  <at>  -57,6 +57,8  <at>  <at>  static void bdev_inode_switch_bdi(struct
 {
 	struct backing_dev_info *old = inode->i_data.backing_dev_info;

+	if (dst == old)
+		return;
 	bdi_lock_two(&old->wb, &dst->wb);
 	spin_lock(&inode->i_lock);
 	inode->i_data.backing_dev_info = dst;
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Chinner | 1 May 2011 09:46

Re: [PATCH 1/3] writeback: introduce wbc.for_sync to cover the two sync stages

On Sun, May 01, 2011 at 06:36:06AM +0800, Wu Fengguang wrote:
> sync(2) is performed in two stages: the WB_SYNC_NONE sync and the
> WB_SYNC_ALL sync. Tag both stages with wbc.for_sync for livelock
> prevention.
> 
> Note that writeback_inodes_sb() is called by not only sync(), they
> are treated the same because the other callers need also need livelock
> prevention.
> 
> Impacts:
> 
> - it changes the order in which pages/inodes are synced to disk. Now in
>   the WB_SYNC_NONE stage, it won't proceed to write the next inode until
>   finished with the current inode.
> 
> - this adds a new field to the writeback trace events and may possibly
>   break some scripts.
.....
> --- linux-next.orig/mm/page-writeback.c	2011-05-01 06:35:16.000000000 +0800
> +++ linux-next/mm/page-writeback.c	2011-05-01 06:35:17.000000000 +0800
>  <at>  <at>  -892,12 +892,12  <at>  <at>  int write_cache_pages(struct address_spa
>  			range_whole = 1;
>  		cycled = 1; /* ignore range_cyclic tests */
>  	}
> -	if (wbc->sync_mode == WB_SYNC_ALL)
> +	if (wbc->for_sync)
>  		tag = PAGECACHE_TAG_TOWRITE;
>  	else
>  		tag = PAGECACHE_TAG_DIRTY;
>  retry:
(Continue reading)

Permalink | Reply | 1 comment |
headers
KOSAKI Motohiro | 1 May 2011 09:47
Favicon

Re: mmotm 2011-04-29-16-25 uploaded

> On Fri, 29 Apr 2011 16:26:16 -0700 akpm <at> linux-foundation.org wrote:
> 
> > The mm-of-the-moment snapshot 2011-04-29-16-25 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > and will soon be available at
> > 
> >    git://zen-kernel.org/kernel/mmotm.git
> > 
> > It contains the following patches against 2.6.39-rc5:
> 
> 
> mm-per-node-vmstat-show-proper-vmstats.patch
> 
> when CONFIG_PROC_FS is not enabled:
> 
> drivers/built-in.o: In function `node_read_vmstat':
> node.c:(.text+0x1e995): undefined reference to `vmstat_text'
> 
> from drivers/base/node.c

Thank you for finding that!

From 63ad7c06f082f8423c033b9f54070e14d561db7e Mon Sep 17 00:00:00 2001
From: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>
Date: Sun, 1 May 2011 16:00:09 +0900
Subject: [PATCH] vmstat: fix build error when SYSFS=y and PROC_FS=n

Randy Dunlap pointed out node.c makes build error when
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matt Dunnington | 1 May 2011 15:03
Picon

jfs_fsck fails at boot, after upgrade to recent kernel

Hi

I'd appreciate some help with an issue that I'm experiencing with my 
root jfs partition being mounted read only at boot, due to jfs_fsck 
returning code 11. Below is a log of what is shown on screen after 
jfs_fsck has been run on the rootfs:

Could not locate device by label or uuid
warning... fsck.jfs for device /dev/md1 exiteds with signal 11
operational error
remounting root filesystem read/write
mount: / not mounted already, or bad option
root filesystem could not be mounted read/write

The issue arose when I upgraded my kernel from 2.6.28-gentoo-r2 to 
2.6.38-gentoo-r3. If I boot my original kernel the system still boots 
fine, but booting the new kernel results in the errors above. Is this a 
bug, or perhaps I have missed something in my kernel configuration?

Many thanks in advance for your kind assistance. Please let me know if 
you need any further information.

Best Regards
Matt Dunnington
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wu Fengguang | 2 May 2011 05:17
Picon
Favicon

[PATCH 1/3] writeback: introduce wbc.tagged_sync for the WB_SYNC_NONE sync stage

sync(2) is performed in two stages: the WB_SYNC_NONE sync and the
WB_SYNC_ALL sync. Tag the first stage with wbc.tagged_sync and do
livelock prevention for it, too.

Note that writeback_inodes_sb() is called by not only sync(), they are
treated the same because the other callers need also need livelock
prevention.

Impacts:

- it changes the order in which pages/inodes are synced to disk. Now in
  the WB_SYNC_NONE stage, it won't proceed to write the next inode until
  finished with the current inode.

- this adds a new field to the writeback trace events and may possibly
  break some scripts.

CC: Jan Kara <jack <at> suse.cz>
CC: Dave Chinner <david <at> fromorbit.com>
Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
---
 fs/ext4/inode.c           |    4 ++--
 fs/fs-writeback.c         |    9 +++++----
 include/linux/writeback.h |    1 +
 mm/page-writeback.c       |    4 ++--
 4 files changed, 10 insertions(+), 8 deletions(-)

--- linux-next.orig/fs/fs-writeback.c	2011-05-02 11:16:12.000000000 +0800
+++ linux-next/fs/fs-writeback.c	2011-05-02 11:17:33.000000000 +0800
 <at>  <at>  -36,6 +36,7  <at>  <at>  struct wb_writeback_work {
(Continue reading)

Permalink | Reply | 4 comments |
headers
Wu Fengguang | 2 May 2011 05:17
Picon
Favicon

[PATCH 0/3] sync livelock fixes v2

Andrew,

changes from v1:
- retain tagged sync behavior for all WB_SYNC_ALL callers (Dave Chinner)
- rename wbc.for_sync to wbc.tagged_sync
- remove the changes to trace events

The below sync livelock test script is working fine after this patchset:

        sync time: 2
        Dirty:             26492 kB
        Writeback:         30260 kB
        NFS_Unstable:          0 kB
        WritebackTmp:          0 kB
        sync NOT livelocked

In particular patch 2 fixes the sync livelock problem introduced by patch
"writeback: try more writeback as long as something was written".

Thanks,
Fengguang
---

#!/bin/sh

umount /dev/sda7
# mkfs.xfs -f /dev/sda7
mkfs.ext4 /dev/sda7
mount /dev/sda7 /fs
(Continue reading)

Permalink | Reply | 18 comments |
headers
Wu Fengguang | 2 May 2011 05:17
Picon
Favicon

[PATCH 2/3] writeback: update dirtied_when for synced inode to prevent livelock

With the more aggressive "keep writeback as long as we wrote something"
logic in wb_writeback(), the "use LONG_MAX .nr_to_write" trick in commit
b9543dac5bbc ("writeback: avoid livelocking WB_SYNC_ALL writeback") is
no longer enough to stop sync livelock.

The fix is to explicitly update .dirtied_when on synced inodes, so that
they are no longer considered for writeback in the next round.

CC: Jan Kara <jack <at> suse.cz>
Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
---
 fs/fs-writeback.c |    9 +++++++++
 1 file changed, 9 insertions(+)

ext3/ext4 are working fine now, however tests show that XFS may still
livelock inside the XFS routines:

[ 3581.181253] sync            D ffff8800b6ca15d8  4560  4403   4392 0x00000000
[ 3581.181734]  ffff88006f775bc8 0000000000000046 ffff8800b6ca12b8 00000001b6ca1938
[ 3581.182411]  ffff88006f774000 00000000001d2e40 00000000001d2e40 ffff8800b6ca1280
[ 3581.183088]  00000000001d2e40 ffff88006f775fd8 00000340af111ef2 00000000001d2e40
[ 3581.183765] Call Trace:
[ 3581.184008]  [<ffffffff8109be73>] ? lock_release_holdtime+0xa3/0xab
[ 3581.184392]  [<ffffffff8108cc0d>] ? prepare_to_wait+0x6c/0x79
[ 3581.184756]  [<ffffffff8108cc0d>] ? prepare_to_wait+0x6c/0x79
[ 3581.185120]  [<ffffffff812ed520>] xfs_ioend_wait+0x87/0x9f
[ 3581.185474]  [<ffffffff8108c97a>] ? wake_up_bit+0x2a/0x2a
[ 3581.185827]  [<ffffffff812f742a>] xfs_sync_inode_data+0x92/0x9d
[ 3581.186198]  [<ffffffff812f76e2>] xfs_inode_ag_walk+0x1a5/0x287
[ 3581.186569]  [<ffffffff812f779b>] ? xfs_inode_ag_walk+0x25e/0x287
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christoph Hellwig | 2 May 2011 10:46
Picon

Re: [PATCH] hfsplus: read support for directory hardlinks

I've applied it with some minor editing to make the indentation
and variable names match the surrounding code a tad better.

Thanks a lot Gustav!

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 10 comments |
headers
Lukas Czerner | 2 May 2011 13:25
Picon
Favicon

[PATCH] sys/block: Add discard_support entry

Currently there is no convenient way how to get the information from
userspace whether or not the block device supports discard other
than try to call BLKDISCARD ioctl and check the result, which is not
really good way to do it.

We already have BLKDISCARDZEROES ioctl and
/sys/block/sda/queue/discard_zeroes_data to tell whether  subsequent
reads after discard returns all zeroes. This commit adds at least sysfs
interface /sys/block/sda/queue/discard_support to tell whether device
support discard.

Signed-off-by: Lukas Czerner <lczerner <at> redhat.com>
Cc: Jens Axboe <jaxboe <at> fusionio.com>
Cc: Jeff Moyer <jmoyer <at> redhat.com>
---
 block/blk-sysfs.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index bd23631..96f1cca 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
 <at>  <at>  -160,6 +160,11  <at>  <at>  static ssize_t queue_discard_zeroes_data_show(struct request_queue *q, char *pag
 	return queue_var_show(queue_discard_zeroes_data(q), page);
 }

+static ssize_t queue_discard_support_show(struct request_queue *q, char *page)
+{
+	return queue_var_show(blk_queue_discard(q), page);
+}
(Continue reading)

Permalink | Reply | 8 comments |
headers
Surbhi Palande | 2 May 2011 13:27
Favicon

Re: [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due to a deadlock

On 05/02/2011 01:56 PM, Jan Kara wrote:
> On Mon 02-05-11 12:07:59, Surbhi Palande wrote:
>> On 04/06/2011 02:21 PM, Dave Chinner wrote:
>>> On Wed, Apr 06, 2011 at 08:18:56AM +0200, Jan Kara wrote:
>>>> On Wed 06-04-11 15:40:05, Dave Chinner wrote:
>>>>> On Fri, Apr 01, 2011 at 04:08:56PM +0200, Jan Kara wrote:
>>>>>> On Fri 01-04-11 10:40:50, Dave Chinner wrote:
>>>>>>> If you don't allow the page to be dirtied in the fist place, then
>>>>>>> nothing needs to be done to the writeback path because there is
>>>>>>> nothing dirty for it to write back.
>>>>>>    Sure but that's only the problem he was able to hit. But generally,
>>>>>> there's a problem with needing s_umount for unfreezing because it isn't
>>>>>> clear there aren't other code paths which can block with s_umount held
>>>>>> waiting for fs to get unfrozen. And these code paths would cause the same
>>>>>> deadlock. That's why I chose to get rid of s_umount during thawing.
>>>>> Holding the s_umount lock while checking if frozen and sleeping
>>>>> is essentially an ABBA lock inversion bug that can bite in many more
>>>>> places that just thawing the filesystem.  Any where this is done should
>>>>> be fixed, so I don't think just removing the s_umount lock from the thaw
>>>>> path is sufficient to avoid problems.
>>>>    That's easily said but hard to do - any transaction start in ext3/4 may
>>>> block on filesystem being frozen (this seems to be similar for XFS as I'm
>>>> looking into the code) and transaction start traditionally nests inside
>>>> s_umount (and basically there's no way around that since sync() calls your
>>>> fs code with s_umount held).
>>> Sure, but the question must be asked - why is ext3/4 even starting a
>>> transaction on a clean filesystem during sync? A frozen filesystem,
>>> by definition, is a clean filesytem, and therefore sync calls of any
>>> kind should not be trying to write to the FS or start transactions.
>>> XFS does this just fine, so I'd consider such behaviour on a frozen
(Continue reading)

Permalink | Reply | 19 comments |

Gmane