All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <chao2.yu@samsung.com>
To: 'Gu Zheng' <guz.fnst@cn.fujitsu.com>
Cc: "'Kim Jaegeuk'" <jaegeuk.kim@gmail.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	'谭姝' <shu.tan@samsung.com>
Subject: RE: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure in bio_alloc
Date: Tue, 17 Sep 2013 11:13:23 +0800	[thread overview]
Message-ID: <000201ceb353$ff0c80b0$fd258210$@samsung.com> (raw)
In-Reply-To: <52368BB2.7000008@cn.fujitsu.com>

Hi Gu

> -----Original Message-----
> From: Gu Zheng [mailto:guz.fnst@cn.fujitsu.com]
> Sent: Monday, September 16, 2013 12:40 PM
> To: Chao Yu
> Cc: 'Kim Jaegeuk'; linux-f2fs-devel@lists.sourceforge.net;
> linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org; '谭姝'
> Subject: Re: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure in
bio_alloc
> 
> Hi Chao,
> 
> On 09/16/2013 11:26 AM, Chao Yu wrote:
> 
> > Hi Gu
> >
> >> -----Original Message-----
> >> From: Gu Zheng [mailto:guz.fnst@cn.fujitsu.com]
> >> Sent: Monday, September 16, 2013 10:09 AM
> >> To: Chao Yu
> >> Cc: Kim Jaegeuk; linux-f2fs-devel@lists.sourceforge.net;
> >> linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org; 谭姝
> >> Subject: Re: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure
> >> in
> > bio_alloc
> >>
> >> Hi Chao,
> >>
> >> On 09/13/2013 09:27 PM, Chao Yu wrote:
> >>
> >>> This patch add macro MAX_BIO_BLOCKS to limit value of npages in
> >>> f2fs_bio_alloc, it can avoid allocating failure in bio_alloc caused
> >>> by npages is larger than UIO_MAXIOV.
> >>
> >> As I know bio_alloc is based of *fs_bio_set* pool, without the
> >> limitation
> > of
> >> UIO_MAXIOV, am I missing something?
> >
> > Here is the code in bio.c, fs_bio_set is as the actual parameter pass
> > to bs without being inited.
> 
> fs_bio_set was initiated early in the bio subsystem init.
> 
> > So it may have opportunity to return NULL in this function.
> 
> It may be, but may not be the thread you mentioned below.
> 
> > ---
> > Bio.c
> > struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct
> > bio_set
> > *bs)
> > {
> > ......
> > 	if (!bs) {
> > 		if (nr_iovecs > UIO_MAXIOV)
> > 			return NULL;
> > ---
> > I did the abnormal test: modify the max_sectors_kb in
> > /sys/block/sdx/queue to 32767 for a disk with f2fs format, and I got a
> > segfualt in f2fs_bio_alloc after the img mounted.
> > Is there anyting I missed?
> 
> Hmm, this change will also trigger bvec_alloc failed, did you add some
traces to
> debug this?

I reviewed the code in bio_alloc, and then trace the process of bio_alloc
for verification.
It indicate that bvec_alloc() will fail on the condition that nr_iovecs is
greater than BIO_MAX_PAGES.
The patch should be updated for that.

I am sorry about the mistake in this patch, and thanks for the reviewing and
reminding.

> 
> Regards,
> Gu
> 
> >
> >>
> >> Thanks,
> >> Gu
> >>
> >>>
> >>> Signed-off-by: Yu Chao <chao2.yu@samsung.com>
> >>>  ---
> >>>  fs/f2fs/segment.c |    4 +++-
> >>>  fs/f2fs/segment.h |    3 +++
> >>>  2 files changed, 6 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index
> >>> 09af9c7..bd79bbe 100644
> >>> --- a/fs/f2fs/segment.c
> >>> +++ b/fs/f2fs/segment.c
> >>> @@ -657,6 +657,7 @@ static void submit_write_page(struct
> >>> f2fs_sb_info *sbi, struct page *page,
> >>>                                 block_t blk_addr, enum page_type
> >> type)
> >>> {
> >>>         struct block_device *bdev = sbi->sb->s_bdev;
> >>> +       int bio_blocks;
> >>>
> >>>         verify_block_addr(sbi, blk_addr);
> >>>
> >>> @@ -676,7 +677,8 @@ retry:
> >>>                         goto retry;
> >>>                 }
> >>>
> >>> -               sbi->bio[type] = f2fs_bio_alloc(bdev,
> > max_hw_blocks(sbi));
> >>> +               bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
> >>> +               sbi->bio[type] = f2fs_bio_alloc(bdev, bio_blocks);
> >>>                 sbi->bio[type]->bi_sector =
> SECTOR_FROM_BLOCK(sbi,
> >>> blk_addr);
> >>>                 sbi->bio[type]->bi_private = priv;
> >>>                 /*
> >>> diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index
> >>> bdd10ea..6352af1 100644
> >>> --- a/fs/f2fs/segment.h
> >>> +++ b/fs/f2fs/segment.h
> >>> @@ -9,6 +9,7 @@
> >>>   * published by the Free Software Foundation.
> >>>   */
> >>>  #include <linux/blkdev.h>
> >>> +#include <linux/uio.h>
> >>>
> >>>  /* constant macro */
> >>>  #define NULL_SEGNO                     ((unsigned int)(~0))
> >>> @@ -90,6 +91,8 @@
> >>>         (blk_addr << ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
> >>> #define SECTOR_TO_BLOCK(sbi, sectors)
> >> \
> >>>         (sectors >> ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
> >>> +#define MAX_BIO_BLOCKS(max_hw_blocks)
> >> \
> >>> +       (min((int)max_hw_blocks, UIO_MAXIOV))
> >>>
> >>>  /* during checkpoint, bio_private is used to synchronize the last
> >>> bio */  struct bio_private {
> >>> ---
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe
> >>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at  http://www.tux.org/lkml/
> >>>
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> 
> 
> =

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu <chao2.yu@samsung.com>
To: "'Gu Zheng'" <guz.fnst@cn.fujitsu.com>
Cc: "'Kim Jaegeuk'" <jaegeuk.kim@gmail.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	'谭姝' <shu.tan@samsung.com>
Subject: RE: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure in bio_alloc
Date: Tue, 17 Sep 2013 11:13:23 +0800	[thread overview]
Message-ID: <000201ceb353$ff0c80b0$fd258210$@samsung.com> (raw)
In-Reply-To: <52368BB2.7000008@cn.fujitsu.com>

Hi Gu

> -----Original Message-----
> From: Gu Zheng [mailto:guz.fnst@cn.fujitsu.com]
> Sent: Monday, September 16, 2013 12:40 PM
> To: Chao Yu
> Cc: 'Kim Jaegeuk'; linux-f2fs-devel@lists.sourceforge.net;
> linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org; '谭姝'
> Subject: Re: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure in
bio_alloc
> 
> Hi Chao,
> 
> On 09/16/2013 11:26 AM, Chao Yu wrote:
> 
> > Hi Gu
> >
> >> -----Original Message-----
> >> From: Gu Zheng [mailto:guz.fnst@cn.fujitsu.com]
> >> Sent: Monday, September 16, 2013 10:09 AM
> >> To: Chao Yu
> >> Cc: Kim Jaegeuk; linux-f2fs-devel@lists.sourceforge.net;
> >> linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org; 谭姝
> >> Subject: Re: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure
> >> in
> > bio_alloc
> >>
> >> Hi Chao,
> >>
> >> On 09/13/2013 09:27 PM, Chao Yu wrote:
> >>
> >>> This patch add macro MAX_BIO_BLOCKS to limit value of npages in
> >>> f2fs_bio_alloc, it can avoid allocating failure in bio_alloc caused
> >>> by npages is larger than UIO_MAXIOV.
> >>
> >> As I know bio_alloc is based of *fs_bio_set* pool, without the
> >> limitation
> > of
> >> UIO_MAXIOV, am I missing something?
> >
> > Here is the code in bio.c, fs_bio_set is as the actual parameter pass
> > to bs without being inited.
> 
> fs_bio_set was initiated early in the bio subsystem init.
> 
> > So it may have opportunity to return NULL in this function.
> 
> It may be, but may not be the thread you mentioned below.
> 
> > ---
> > Bio.c
> > struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct
> > bio_set
> > *bs)
> > {
> > ......
> > 	if (!bs) {
> > 		if (nr_iovecs > UIO_MAXIOV)
> > 			return NULL;
> > ---
> > I did the abnormal test: modify the max_sectors_kb in
> > /sys/block/sdx/queue to 32767 for a disk with f2fs format, and I got a
> > segfualt in f2fs_bio_alloc after the img mounted.
> > Is there anyting I missed?
> 
> Hmm, this change will also trigger bvec_alloc failed, did you add some
traces to
> debug this?

I reviewed the code in bio_alloc, and then trace the process of bio_alloc
for verification.
It indicate that bvec_alloc() will fail on the condition that nr_iovecs is
greater than BIO_MAX_PAGES.
The patch should be updated for that.

I am sorry about the mistake in this patch, and thanks for the reviewing and
reminding.

> 
> Regards,
> Gu
> 
> >
> >>
> >> Thanks,
> >> Gu
> >>
> >>>
> >>> Signed-off-by: Yu Chao <chao2.yu@samsung.com>
> >>>  ---
> >>>  fs/f2fs/segment.c |    4 +++-
> >>>  fs/f2fs/segment.h |    3 +++
> >>>  2 files changed, 6 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index
> >>> 09af9c7..bd79bbe 100644
> >>> --- a/fs/f2fs/segment.c
> >>> +++ b/fs/f2fs/segment.c
> >>> @@ -657,6 +657,7 @@ static void submit_write_page(struct
> >>> f2fs_sb_info *sbi, struct page *page,
> >>>                                 block_t blk_addr, enum page_type
> >> type)
> >>> {
> >>>         struct block_device *bdev = sbi->sb->s_bdev;
> >>> +       int bio_blocks;
> >>>
> >>>         verify_block_addr(sbi, blk_addr);
> >>>
> >>> @@ -676,7 +677,8 @@ retry:
> >>>                         goto retry;
> >>>                 }
> >>>
> >>> -               sbi->bio[type] = f2fs_bio_alloc(bdev,
> > max_hw_blocks(sbi));
> >>> +               bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
> >>> +               sbi->bio[type] = f2fs_bio_alloc(bdev, bio_blocks);
> >>>                 sbi->bio[type]->bi_sector =
> SECTOR_FROM_BLOCK(sbi,
> >>> blk_addr);
> >>>                 sbi->bio[type]->bi_private = priv;
> >>>                 /*
> >>> diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index
> >>> bdd10ea..6352af1 100644
> >>> --- a/fs/f2fs/segment.h
> >>> +++ b/fs/f2fs/segment.h
> >>> @@ -9,6 +9,7 @@
> >>>   * published by the Free Software Foundation.
> >>>   */
> >>>  #include <linux/blkdev.h>
> >>> +#include <linux/uio.h>
> >>>
> >>>  /* constant macro */
> >>>  #define NULL_SEGNO                     ((unsigned int)(~0))
> >>> @@ -90,6 +91,8 @@
> >>>         (blk_addr << ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
> >>> #define SECTOR_TO_BLOCK(sbi, sectors)
> >> \
> >>>         (sectors >> ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
> >>> +#define MAX_BIO_BLOCKS(max_hw_blocks)
> >> \
> >>> +       (min((int)max_hw_blocks, UIO_MAXIOV))
> >>>
> >>>  /* during checkpoint, bio_private is used to synchronize the last
> >>> bio */  struct bio_private {
> >>> ---
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe
> >>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at  http://www.tux.org/lkml/
> >>>
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> 
> 
> =


  reply	other threads:[~2013-09-17  3:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13 13:27 [PATCH RESEND] f2fs: avoid allocating failure in bio_alloc Chao Yu
2013-09-13 13:27 ` [f2fs-dev][PATCH " Chao Yu
2013-09-16  2:09 ` Gu Zheng
2013-09-16  3:26   ` [PATCH " Chao Yu
2013-09-16  3:26     ` [f2fs-dev][PATCH " Chao Yu
2013-09-16  4:40     ` Gu Zheng
2013-09-16  4:40       ` Gu Zheng
2013-09-17  3:13       ` Chao Yu [this message]
2013-09-17  3:13         ` Chao Yu

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='000201ceb353$ff0c80b0$fd258210$@samsung.com' \
    --to=chao2.yu@samsung.com \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=jaegeuk.kim@gmail.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shu.tan@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.