From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: WDunphy-/3AnZwnt+WyVkR+q5Y5grQ@public.gmane.org
Cc: users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org,
konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org
Subject: Re: Write hang on ARM based target
Date: Fri, 19 Jun 2009 03:42:51 +0900 (JST) [thread overview]
Message-ID: <20090619.034251.67908874.ryusuke@osrg.net> (raw)
In-Reply-To: <20090619.033642.32757627.ryusuke-sG5X7nlA6pw@public.gmane.org>
On Fri, 19 Jun 2009 03:36:42 +0900 (JST), Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org> wrote:
> Hi,
> On Fri, 12 Jun 2009 13:23:44 +0900 (JST), Ryusuke Konishi wrote:
> > On Tue, 9 Jun 2009 13:04:04 -0600, "Dunphy, Bill" wrote:
> > >
> > > Ryusuke,
> > >
> > > I've simplified my test approach by simply copying a single 10 byte file
> > > repeatedly. When doing so, I get consistent NILFS log output at the
> > > time of hang. Examination of /proc/sysreq-trigger also shows the copy
> > > process to be in the same state as before (at sys_write).
> >
> > Thank you for sending me the trace log. I will look into the problem
> > later.
> >
> > Ryusuke Konishi
>
> In another thread, I've sent a patch that may cause the hang problem.
> Here, I attach the out-of-tree version of the patch.
s/cause/fix/
Ryusuke
> Does this make a difference in your problem ?
>
> Thanks,
> Ryusuke Konishi
> --
>
> diff --git a/fs/dat.c b/fs/dat.c
> index 036b05d..b05d9d4 100644
> --- a/fs/dat.c
> +++ b/fs/dat.c
> @@ -149,15 +149,6 @@ void nilfs_dat_commit_start(struct inode *dat, struct nilfs_palloc_req *req,
> entry = nilfs_palloc_block_get_entry(dat, req->pr_entry_nr,
> req->pr_entry_bh, kaddr);
> entry->de_start = cpu_to_le64(nilfs_mdt_cno(dat));
> - if (entry->de_blocknr != cpu_to_le64(0) ||
> - entry->de_end != cpu_to_le64(NILFS_CNO_MAX)) {
> - printk(KERN_CRIT
> - "%s: vbn = %llu, start = %llu, end = %llu, pbn = %llu\n",
> - __func__, (unsigned long long)req->pr_entry_nr,
> - (unsigned long long)le64_to_cpu(entry->de_start),
> - (unsigned long long)le64_to_cpu(entry->de_end),
> - (unsigned long long)le64_to_cpu(entry->de_blocknr));
> - }
> entry->de_blocknr = cpu_to_le64(blocknr);
> kunmap_atomic(kaddr, KM_USER0);
>
> diff --git a/fs/segment.c b/fs/segment.c
> index 3cbb3fe..225d5ae 100644
> --- a/fs/segment.c
> +++ b/fs/segment.c
> @@ -2009,26 +2009,13 @@ static int nilfs_segctor_write(struct nilfs_sc_info *sci,
> err = nilfs_segbuf_write(segbuf, &wi);
>
> res = nilfs_segbuf_wait(segbuf, &wi);
> - err = unlikely(err) ? : res;
> + err = unlikely(err) ? err : res;
> if (unlikely(err))
> return err;
> }
> return 0;
> }
>
> -static int nilfs_page_has_uncleared_buffer(struct page *page)
> -{
> - struct buffer_head *head, *bh;
> -
> - head = bh = page_buffers(page);
> - do {
> - if (buffer_dirty(bh) && !list_empty(&bh->b_assoc_buffers))
> - return 1;
> - bh = bh->b_this_page;
> - } while (bh != head);
> - return 0;
> -}
> -
> static void __nilfs_end_page_io(struct page *page, int err)
> {
> if (!err) {
> @@ -2056,12 +2043,11 @@ static void nilfs_end_page_io(struct page *page, int err)
> if (!page)
> return;
>
> - if (buffer_nilfs_node(page_buffers(page)) &&
> - nilfs_page_has_uncleared_buffer(page))
> - /* For b-tree node pages, this function may be called twice
> - or more because they might be split in a segment.
> - This check assures that cleanup has been done for all
> - buffers in a split btnode page. */
> + if (buffer_nilfs_node(page_buffers(page)) && !PageWriteback(page))
> + /*
> + * For b-tree node pages, this function may be called twice
> + * or more because they might be split in a segment.
> + */
> return;
>
> __nilfs_end_page_io(page, err);
> @@ -2125,7 +2111,7 @@ static void nilfs_segctor_abort_write(struct nilfs_sc_info *sci,
> }
> if (bh->b_page != fs_page) {
> nilfs_end_page_io(fs_page, err);
> - if (unlikely(fs_page == failed_page))
> + if (fs_page && fs_page == failed_page)
> goto done;
> fs_page = bh->b_page;
> }
> _______________________________________________
> users mailing list
> users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
> https://www.nilfs.org/mailman/listinfo/users
next prev parent reply other threads:[~2009-06-18 18:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 15:46 [SPAM] Write hang on ARM based target Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F8D-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-08 16:49 ` Ryusuke Konishi
[not found] ` <20090609.014919.79903506.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-08 20:30 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F96-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-09 19:04 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F99-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-12 4:23 ` Ryusuke Konishi
[not found] ` <20090612.132344.17157054.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-18 18:36 ` Ryusuke Konishi
[not found] ` <20090619.033642.32757627.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-18 18:42 ` Ryusuke Konishi [this message]
2009-06-18 19:48 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FAC-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-19 1:47 ` Ryusuke Konishi
[not found] ` <20090619.104731.99018736.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-19 15:01 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FB3-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-22 18:58 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FB9-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-23 3:35 ` Ryusuke Konishi
[not found] ` <20090623.123505.37056161.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-23 15:34 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FBB-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-24 21:16 ` Dunphy, Bill
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=20090619.034251.67908874.ryusuke@osrg.net \
--to=ryusuke-sg5x7nla6pw@public.gmane.org \
--cc=WDunphy-/3AnZwnt+WyVkR+q5Y5grQ@public.gmane.org \
--cc=konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
--cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org \
/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