[Bug 208805] XFS: iozone possible memory allocation deadlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.kernel.org/show_bug.cgi?id=208805

--- Comment #1 from bfoster@xxxxxxxxxx ---
On Tue, Aug 04, 2020 at 09:52:48AM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxx
>           Reporter: jjzuming@xxxxxxxxxxx
>         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.
>

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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux