From: Alex Elder <aelder@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Bartosz Cisek <bartosz.cisek@nasza-klasa.pl>,
Michael Monnerie <michael.monnerie@is.it-management.at>,
xfs@oss.sgi.com
Subject: Re: xfs_repair segfaut in stage 6
Date: Tue, 20 Sep 2011 15:25:41 -0500 [thread overview]
Message-ID: <1316550341.2912.54.camel@doink> (raw)
In-Reply-To: <20110914153852.GA11050@infradead.org>
On Wed, 2011-09-14 at 11:38 -0400, Christoph Hellwig wrote:
> On Wed, Sep 14, 2011 at 04:59:40PM +0200, Bartosz Cisek wrote:
> > Stack trace is pasted in bug issue [1] that is linked in first mail ;)
> > Compiled by hand from git: "DEBUG=-DDEBUG make". I don't know why some
> > of values are 'optimized out'.
> >
> > [1] http://oss.sgi.com/bugzilla/show_bug.cgi?id=914
>
> Looks like we do not handle read I/O errors very well (to say at all)
> in phase6. Can you see if the patch below makes a difference?
Christoph, I'm assuming you want this reviewed
as a submitted patch.
> ---
> From: Christoph Hellwig <hch@lst.de>
> Subject: repair: fix I/O error handling
>
> Currently libxfs_trans_read_buf never returns an error, even if
> libxfs_readbuf did not manage to complete the I/O. This is different
> from the kernel behaviour and can lead to segfaults in code that
> doesn't expect it. Add a new b_error member to xfs_buf (mirroring
> the kernel version) and use that to propagate proper error codes
> to the caller. Also fix libxfs_readbufr to handle short reads
> properly, and to not override errno values e.g. by a fprintf.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Index: xfsprogs-dev/include/libxfs.h
> ===================================================================
> --- xfsprogs-dev.orig/include/libxfs.h 2011-09-14 11:17:42.660738577 -0400
> +++ xfsprogs-dev/include/libxfs.h 2011-09-14 11:20:45.959738580 -0400
> @@ -230,6 +230,7 @@ typedef struct xfs_buf {
> void *b_fsprivate2;
> void *b_fsprivate3;
> char *b_addr;
> + int b_error;
> #ifdef XFS_BUF_TRACING
> struct list_head b_lock_list;
> const char *b_func;
> Index: xfsprogs-dev/libxfs/rdwr.c
> ===================================================================
> --- xfsprogs-dev.orig/libxfs/rdwr.c 2011-09-14 11:12:08.807741720 -0400
> +++ xfsprogs-dev/libxfs/rdwr.c 2011-09-14 11:20:21.183238272 -0400
> @@ -314,6 +314,7 @@ libxfs_initbuf(xfs_buf_t *bp, dev_t devi
> bp->b_blkno = bno;
> bp->b_bcount = bytes;
> bp->b_dev = device;
> + bp->b_error = 0;
> if (!bp->b_addr)
> bp->b_addr = memalign(libxfs_device_alignment(), bytes);
> if (!bp->b_addr) {
> @@ -454,15 +455,17 @@ libxfs_readbufr(dev_t dev, xfs_daddr_t b
> {
> int fd = libxfs_device_to_fd(dev);
> int bytes = BBTOB(len);
> + int error;
>
> ASSERT(BBTOB(len) <= bp->b_bcount);
>
> - if (pread64(fd, bp->b_addr, bytes, LIBXFS_BBTOOFF64(blkno)) < 0) {
> + if (pread64(fd, bp->b_addr, bytes, LIBXFS_BBTOOFF64(blkno)) != bytes) {
If we reach EOF this returns 0, but errno is I think
going to be 0. Do we want to print a "read failed"
message in that case? Is EOF a failure, or just
a somewhat normal condition?
Also, it may not matter in the calling code (I
did only a quick check) but maybe it would be
better to set bp->b_error here, where the error
really occurred, rather than in libxfs_readbuf().
Other than that, this change looks good to me.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-09-20 20:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 8:43 xfs_repair segfaut in stage 6 Bartosz Cisek
2011-09-09 12:01 ` Michael Monnerie
2011-09-09 15:06 ` Bartosz Cisek
2011-09-12 15:42 ` Bartosz Cisek
2011-09-12 15:58 ` Christoph Hellwig
2011-09-12 16:12 ` Christoph Hellwig
2011-09-14 9:38 ` Bartosz Cisek
2011-09-14 14:24 ` Christoph Hellwig
2011-09-14 14:57 ` Eric Sandeen
2011-09-14 15:10 ` Bartosz Cisek
2011-09-14 15:23 ` Eric Sandeen
2011-09-14 14:59 ` Bartosz Cisek
2011-09-14 15:38 ` Christoph Hellwig
2011-09-14 16:05 ` Bartosz Cisek
2011-09-20 20:25 ` Alex Elder [this message]
2011-09-20 20:28 ` Christoph Hellwig
2011-09-09 12:38 ` Christoph Hellwig
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=1316550341.2912.54.camel@doink \
--to=aelder@sgi.com \
--cc=bartosz.cisek@nasza-klasa.pl \
--cc=hch@infradead.org \
--cc=michael.monnerie@is.it-management.at \
--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