From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-xfs@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
Brian Foster <bfoster@redhat.com>
Subject: Re: [PATCH] fs: xfs: xfs_log: Don't use KM_MAYFAIL at xfs_log_reserve().
Date: Thu, 1 Aug 2019 13:46:51 -0700 [thread overview]
Message-ID: <20190801204651.GE7138@magnolia> (raw)
In-Reply-To: <1564653995-9004-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On Thu, Aug 01, 2019 at 07:06:35PM +0900, Tetsuo Handa wrote:
> When the system is close-to-OOM, fsync() may fail due to -ENOMEM because
> xfs_log_reserve() is using KM_MAYFAIL. It is a bad thing to fail writeback
> operation due to user-triggerable OOM condition. Since we are not using
> KM_MAYFAIL at xfs_trans_alloc() before calling xfs_log_reserve(), let's
> use the same flags at xfs_log_reserve().
>
> oom-torture: page allocation failure: order:0, mode:0x46c40(GFP_NOFS|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), nodemask=(null)
> CPU: 7 PID: 1662 Comm: oom-torture Kdump: loaded Not tainted 5.3.0-rc2+ #925
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00
> Call Trace:
> dump_stack+0x67/0x95
> warn_alloc+0xa9/0x140
> __alloc_pages_slowpath+0x9a8/0xbce
> __alloc_pages_nodemask+0x372/0x3b0
> alloc_slab_page+0x3a/0x8d0
> new_slab+0x330/0x420
> ___slab_alloc.constprop.94+0x879/0xb00
> __slab_alloc.isra.89.constprop.93+0x43/0x6f
> kmem_cache_alloc+0x331/0x390
> kmem_zone_alloc+0x9f/0x110 [xfs]
> kmem_zone_alloc+0x9f/0x110 [xfs]
> xlog_ticket_alloc+0x33/0xd0 [xfs]
> xfs_log_reserve+0xb4/0x410 [xfs]
> xfs_trans_reserve+0x1d1/0x2b0 [xfs]
> xfs_trans_alloc+0xc9/0x250 [xfs]
> xfs_setfilesize_trans_alloc.isra.27+0x44/0xc0 [xfs]
> xfs_submit_ioend.isra.28+0xa5/0x180 [xfs]
> xfs_vm_writepages+0x76/0xa0 [xfs]
> do_writepages+0x17/0x80
> __filemap_fdatawrite_range+0xc1/0xf0
> file_write_and_wait_range+0x53/0xa0
> xfs_file_fsync+0x87/0x290 [xfs]
> vfs_fsync_range+0x37/0x80
> do_fsync+0x38/0x60
> __x64_sys_fsync+0xf/0x20
> do_syscall_64+0x4a/0x1c0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Looks ok...
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
--D
> ---
> fs/xfs/xfs_log.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
> index 00e9f5c388d3..7fc3c1ad36bc 100644
> --- a/fs/xfs/xfs_log.c
> +++ b/fs/xfs/xfs_log.c
> @@ -429,10 +429,7 @@ xfs_log_reserve(
>
> ASSERT(*ticp == NULL);
> tic = xlog_ticket_alloc(log, unit_bytes, cnt, client, permanent,
> - KM_SLEEP | KM_MAYFAIL);
> - if (!tic)
> - return -ENOMEM;
> -
> + KM_SLEEP);
> *ticp = tic;
>
> xlog_grant_push_ail(log, tic->t_cnt ? tic->t_unit_res * tic->t_cnt
> --
> 2.16.5
>
prev parent reply other threads:[~2019-08-01 20:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-25 10:06 xfs: garbage file data inclusion bug under memory pressure Tetsuo Handa
2019-07-25 10:53 ` Brian Foster
2019-07-25 12:30 ` Tetsuo Handa
2019-07-25 16:00 ` Brian Foster
2019-07-25 11:32 ` Dave Chinner
2019-07-25 12:44 ` Tetsuo Handa
2019-07-25 17:28 ` Darrick J. Wong
2019-07-25 22:07 ` Dave Chinner
2019-07-29 3:50 ` Tetsuo Handa
2019-07-29 11:23 ` Brian Foster
2019-07-29 21:56 ` Dave Chinner
2019-07-30 11:30 ` Brian Foster
2019-08-01 10:06 ` [PATCH] fs: xfs: xfs_log: Don't use KM_MAYFAIL at xfs_log_reserve() Tetsuo Handa
2019-08-01 10:56 ` Brian Foster
2019-08-01 11:00 ` Tetsuo Handa
2019-08-01 18:50 ` Luis Chamberlain
2019-08-01 20:46 ` Darrick J. Wong
2019-08-02 22:21 ` Luis Chamberlain
2019-08-12 10:57 ` Tetsuo Handa
2019-08-12 19:55 ` Darrick J. Wong
2019-08-01 21:13 ` Tetsuo Handa
2019-08-01 21:55 ` Dave Chinner
2019-08-01 20:46 ` Darrick J. Wong [this message]
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=20190801204651.GE7138@magnolia \
--to=darrick.wong@oracle.com \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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).