All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@aol.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Gao Xiang <gaoxiang25@huawei.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: bio_alloc should never fail
Date: Thu, 31 Oct 2019 00:52:39 +0800	[thread overview]
Message-ID: <20191030165226.GC3953@hsiangkao-HP-ZHAN-66-Pro-G1> (raw)
In-Reply-To: <20191030163313.GB34056@jaegeuk-macbookpro.roam.corp.google.com>

On Wed, Oct 30, 2019 at 09:33:13AM -0700, Jaegeuk Kim wrote:
> On 10/30, Theodore Y. Ts'o wrote:
> > On Wed, Oct 30, 2019 at 11:50:37PM +0800, Gao Xiang wrote:
> > > 
> > > So I'm curious about the original issue in commit 740432f83560
> > > ("f2fs: handle failed bio allocation"). Since f2fs manages multiple write
> > > bios with its internal fio but it seems the commit is not helpful to
> > > resolve potential mempool deadlock (I'm confused since no calltrace,
> > > maybe I'm wrong)...
> > 
> > Two possibilities come to mind.  (a) It may be that on older kernels
> > (when f2fs is backported to older Board Support Package kernels from
> > the SOC vendors) didn't have the bio_alloc() guarantee, so it was
> > necessary on older kernels, but not on upstream, or (b) it wasn't
> > *actually* possible for bio_alloc() to fail and someone added the
> > error handling in 740432f83560 out of paranoia.
> 
> Yup, I was checking old device kernels but just stopped digging it out.
> Instead, I hesitate to apply this patch since I can't get why we need to
> get rid of this code for clean-up purpose. This may be able to bring
> some hassles when backporting to android/device kernels.

Yes, got you concern. As I said in other patches for many times, since
you're the maintainer of f2fs, it's all up to you (I'm not paranoia).
However, I think there are 2 valid reasons:

 1) As a newbie of Linux filesystem. When I study or work on f2fs,
    and I saw these misleading code, I think I will produce similar
    code in the future (not everyone refers comments above bio_alloc),
    so such usage will spread (since one could refer some sample code
    from exist code);

 2) Since it's upstream, I personally think appropriate cleanup is ok (anyway
    it kills net 20+ line dead code), and this patch I think isn't so harmful
    for backporting.

Thanks,
Gao Xiang

> 
> > 
> > (Hence my suggestion that in the ext4 version of the patch, we add a
> > code comment justifying why there was no error checking, to make it
> > clear that this was a deliberate choice.  :-)
> > 
> > 						- Ted

WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-doc@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	"Theodore Y. Ts'o" <tytso@mit.edu>
Subject: Re: [f2fs-dev] [PATCH] f2fs: bio_alloc should never fail
Date: Thu, 31 Oct 2019 00:52:39 +0800	[thread overview]
Message-ID: <20191030165226.GC3953@hsiangkao-HP-ZHAN-66-Pro-G1> (raw)
In-Reply-To: <20191030163313.GB34056@jaegeuk-macbookpro.roam.corp.google.com>

On Wed, Oct 30, 2019 at 09:33:13AM -0700, Jaegeuk Kim wrote:
> On 10/30, Theodore Y. Ts'o wrote:
> > On Wed, Oct 30, 2019 at 11:50:37PM +0800, Gao Xiang wrote:
> > > 
> > > So I'm curious about the original issue in commit 740432f83560
> > > ("f2fs: handle failed bio allocation"). Since f2fs manages multiple write
> > > bios with its internal fio but it seems the commit is not helpful to
> > > resolve potential mempool deadlock (I'm confused since no calltrace,
> > > maybe I'm wrong)...
> > 
> > Two possibilities come to mind.  (a) It may be that on older kernels
> > (when f2fs is backported to older Board Support Package kernels from
> > the SOC vendors) didn't have the bio_alloc() guarantee, so it was
> > necessary on older kernels, but not on upstream, or (b) it wasn't
> > *actually* possible for bio_alloc() to fail and someone added the
> > error handling in 740432f83560 out of paranoia.
> 
> Yup, I was checking old device kernels but just stopped digging it out.
> Instead, I hesitate to apply this patch since I can't get why we need to
> get rid of this code for clean-up purpose. This may be able to bring
> some hassles when backporting to android/device kernels.

Yes, got you concern. As I said in other patches for many times, since
you're the maintainer of f2fs, it's all up to you (I'm not paranoia).
However, I think there are 2 valid reasons:

 1) As a newbie of Linux filesystem. When I study or work on f2fs,
    and I saw these misleading code, I think I will produce similar
    code in the future (not everyone refers comments above bio_alloc),
    so such usage will spread (since one could refer some sample code
    from exist code);

 2) Since it's upstream, I personally think appropriate cleanup is ok (anyway
    it kills net 20+ line dead code), and this patch I think isn't so harmful
    for backporting.

Thanks,
Gao Xiang

> 
> > 
> > (Hence my suggestion that in the ext4 version of the patch, we add a
> > code comment justifying why there was no error checking, to make it
> > clear that this was a deliberate choice.  :-)
> > 
> > 						- Ted


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2019-10-30 16:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30  3:55 [PATCH] f2fs: bio_alloc should never fail Gao Xiang
2019-10-30  3:55 ` [f2fs-dev] " Gao Xiang
2019-10-30  8:56 ` Chao Yu
2019-10-30  8:56   ` Chao Yu
2019-10-30  9:15   ` Gao Xiang
2019-10-30  9:15     ` Gao Xiang
2019-10-30  9:27     ` Chao Yu
2019-10-30  9:27       ` Chao Yu
2019-10-30 10:43       ` Gao Xiang
2019-10-30 10:43         ` Gao Xiang
2019-10-30 15:14         ` Theodore Y. Ts'o
2019-10-30 15:14           ` Theodore Y. Ts'o
2019-10-30 15:50           ` Gao Xiang
2019-10-30 15:50             ` Gao Xiang via Linux-f2fs-devel
2019-10-30 16:22             ` Theodore Y. Ts'o
2019-10-30 16:22               ` Theodore Y. Ts'o
2019-10-30 16:33               ` Jaegeuk Kim
2019-10-30 16:33                 ` Jaegeuk Kim
2019-10-30 16:52                 ` Gao Xiang [this message]
2019-10-30 16:52                   ` Gao Xiang via Linux-f2fs-devel
2019-10-31  6:55                 ` Chao Yu
2019-10-31  6:55                   ` Chao Yu
2019-10-31  2:03           ` Chao Yu
2019-10-31  2:03             ` 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=20191030165226.GC3953@hsiangkao-HP-ZHAN-66-Pro-G1 \
    --to=hsiangkao@aol.com \
    --cc=corbet@lwn.net \
    --cc=gaoxiang25@huawei.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.