Hi Ryusuke,
On Tue, 2013-07-23 at 03:24 +0900, Ryusuke Konishi wrote:
[snip]
>
> Thank you for following the issue. I reviewed the code around bio.
>
> In conclusion, Dan Carpenter's patch looks correct because
> nilfs_segbuf_submit_bio() does not increment the number of flying bio
> (segbuf->sb_nbio) for EOPNOTSUPP/BIO_EOPNOTSUPP case.
>
I worry that nilfs_end_bio_write() is called asynchronously. And, as I
understand, the BIO_EOPNOTSUPP flag is set during nilfs_end_bio_write()
call. It means for me that sometimes segbuf->sb_nbio will be not
incremented in nilfs_segbuf_submit_bio() but sometimes this field can be
incremented and for BIO_EOPNOTSUPP case.
> If nilfs_end_bio_write() function reaches the complete() call for the
> EOPNOTSUPP/BIO_EOPNOTSUPP case (as the current implementation), the
> number of complete() calls and that of wait_for_complete() will not
> balance.
>
I think that it is dangerous to return without complete() call because
of asynchronous nature of nilfs_end_bio_write() call.
What do you think?
With the best regards,
Vyacheslav Dubeyko.
> Do you have a comment?
>
> Regards,
> Ryusuke Konishi
>
> > ---
> > fs/nilfs2/segbuf.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/fs/nilfs2/segbuf.c b/fs/nilfs2/segbuf.c
> > index dc9a913..5bacf46 100644
> > --- a/fs/nilfs2/segbuf.c
> > +++ b/fs/nilfs2/segbuf.c
> > @@ -345,8 +345,7 @@ static void nilfs_end_bio_write(struct bio *bio, int err)
> >
> > if (err == -EOPNOTSUPP) {
> > set_bit(BIO_EOPNOTSUPP, &bio->bi_flags);
> > - bio_put(bio);
> > - /* to be detected by submit_seg_bio() */
> > + /* to be detected by nilfs_segbuf_submit_bio() */
> > }
> >
> > if (!uptodate)
> > --
> > 1.7.9.5
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
