public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: bugzilla-daemon@bugzilla.kernel.org
Cc: linux-xfs@vger.kernel.org
Subject: Re: [Bug 208805] New: XFS: iozone possible memory allocation deadlock
Date: Wed, 26 Aug 2020 11:19:58 -0400	[thread overview]
Message-ID: <20200826151958.GB355692@bfoster> (raw)
In-Reply-To: <bug-208805-201763@https.bugzilla.kernel.org/>

On Tue, Aug 04, 2020 at 09:52:48AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208805
> 
>             Bug ID: 208805
>            Summary: XFS: iozone possible memory allocation deadlock
>            Product: File System
>            Version: 2.5
>     Kernel Version: Linux 5.4
>           Hardware: x86-64
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: XFS
>           Assignee: filesystem_xfs@kernel-bugs.kernel.org
>           Reporter: jjzuming@outlook.com
>         Regression: No
> 
> When I ran iozone to test XFS in a memory insufficient situation,I found that
> iozone was blocked and The log "XFS: iozone possible memory allocation
> deadlock" was printed.
> 
> Reviewing the XFS code, I found that kmem_alloc(), xfs_buf_allocate_memory(),
> kmem_zone_alloc() and kmem_realloc() were implemented with "while" loops. These
> functions kept trying to get memory while the memory was insufficient, as a
> result of which "memory allocation deadlock" happened.
> 
> I think it may be a little unreasonable, although it can guarantee that the
> memory allocation succeed. Maybe using error handling code to handle the memory
> allocation failures is better.
> 

I think some of this memory allocation code is currently being reworked,
but that aside most of the above cases do break the retry loop if the
caller passes KM_MAYFAIL. So it's a case by case basis as to whether a
particular allocation should be allowed to fail and potentially return
an error to userspace or should continue to retry.

A more useful approach to this bug would be to describe your test, the
specific system/memory conditions, and provide the full log output
(stack trace?) associated with the issue. Then perhaps we can analyze
the cause and determine whether it's something that can be addressed or
improved, or if you just need more memory. ;)

Brian

> -- 
> You are receiving this mail because:
> You are watching the assignee of the bug.
> 


  reply	other threads:[~2020-08-26 15:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04  9:52 [Bug 208805] New: XFS: iozone possible memory allocation deadlock bugzilla-daemon
2020-08-26 15:19 ` Brian Foster [this message]
2020-08-26 15:20 ` [Bug 208805] " bugzilla-daemon

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=20200826151958.GB355692@bfoster \
    --to=bfoster@redhat.com \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-xfs@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