From: Eric Sandeen <sandeen@sandeen.net>
To: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: mkfs.xfs pagefault when removed storage during operation
Date: Wed, 02 Feb 2011 22:10:03 -0600 [thread overview]
Message-ID: <4D4A2A9B.6090803@sandeen.net> (raw)
In-Reply-To: <AANLkTi=wi_Fhr5v1J4wopvFTY=hC2EA_QmJu4Uc_XgGs@mail.gmail.com>
On 2/1/11 5:06 AM, Ajeet Yadav wrote:
> We are testing mkfs.xfs and xfs_repair stability to look for crashes
> and other issues specially with removable devices.
> And unfortunately crashes does occur.
> Code inspection shows in most cases the caller does not handle
> libxfs_readbuf() for error cases i.e when return value = NULL.
>
> Now I need your suggestion.
> We should fix all such cases or the simplest way is to exit... if
> read() or write() fails with EIO errorno in libxfs_readbufr() and
> libxfs_writebufr().
I see very little reason to gracefully handle all error cases
during mkfs. It would be prettier, yes, but if mkfs fails, with
or without an error, with or without a segfault, you have to
just start it over anyway, right?
I think there are better places to focus effort.
-Eric
> Fortunately these function already support exit, if we use flag
> LIBXFS_EXIT_ON_FAILURE, LIBXFS_B_EXIT but they are used selectively.
>
> The current problem is related to function libxfs_trans_read_buf()
>
> bp = libxfs_readbuf(dev, blkno, len, flags);
> #ifdef XACT_DEBUG
> fprintf(stderr, "trans_read_buf buffer %p, transaction %p\n", bp, tp);
> #endif
> xfs_buf_item_init(bp, tp->t_mountp);
> bip = XFS_BUF_FSPRIVATE(bp, xfs_buf_log_item_t *);
> bip->bli_recur = 0;
> xfs_trans_add_item(tp, (xfs_log_item_t *)bip);
>
> /* initialise b_fsprivate2 so we can find it incore */
> XFS_BUF_SET_FSPRIVATE2(bp, tp);
> *bpp = bp;
> return 0;
>
> if libxfs_readbuf() fails due to device removal or other error, bp = NULL.
> In function xfs_buf_item_init(bp, tp->t_mountp) as soon as bp is
> dereferenced occurs
>
> mkfs.xfs: unhandled page fault (11) at 0x00000070, code 0x017
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-02-03 4:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 11:06 mkfs.xfs pagefault when removed storage during operation Ajeet Yadav
2011-02-02 8:09 ` Ajeet Yadav
2011-02-08 1:35 ` Alex Elder
2011-02-08 2:27 ` Ajeet Yadav
2011-02-03 4:10 ` Eric Sandeen [this message]
2011-02-03 6:03 ` Ajeet Yadav
2011-02-03 6:07 ` Eric Sandeen
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=4D4A2A9B.6090803@sandeen.net \
--to=sandeen@sandeen.net \
--cc=ajeet.yadav.77@gmail.com \
--cc=xfs@oss.sgi.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