linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Gao Xiang <hsiangkao@aol.com>
Cc: 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,
	Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [f2fs-dev] [PATCH] f2fs: bio_alloc should never fail
Date: Wed, 30 Oct 2019 12:22:43 -0400	[thread overview]
Message-ID: <20191030162243.GA18729@mit.edu> (raw)
In-Reply-To: <20191030155020.GA3953@hsiangkao-HP-ZHAN-66-Pro-G1>

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.

(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

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

Thread overview: 12+ 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  8:56 ` [f2fs-dev] " Chao Yu
2019-10-30  9:15   ` Gao Xiang
2019-10-30  9:27     ` Chao Yu
2019-10-30 10:43       ` Gao Xiang
2019-10-30 15:14         ` Theodore Y. Ts'o
2019-10-30 15:50           ` Gao Xiang
2019-10-30 16:22             ` Theodore Y. Ts'o [this message]
2019-10-30 16:33               ` Jaegeuk Kim
2019-10-30 16:52                 ` Gao Xiang
2019-10-31  6:55                 ` 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=20191030162243.GA18729@mit.edu \
    --to=tytso@mit.edu \
    --cc=corbet@lwn.net \
    --cc=gaoxiang25@huawei.com \
    --cc=hsiangkao@aol.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).