Thread (46 messages) 46 messages, 9 authors, 2017-03-06

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

From: Michal Hocko <mhocko@kernel.org>
Date: 2017-01-30 08:12:10
Also in: ceph-devel, linux-f2fs-devel, linux-fsdevel, linux-mm, linux-nfs, linux-xfs, lkml

On Fri 27-01-17 11:40:42, Theodore Ts'o wrote:
On Fri, Jan 27, 2017 at 10:37:35AM +0100, Michal Hocko wrote:
quoted
If this ever turn out to be a problem and with the vmapped stacks we
have good chances to get a proper stack traces on a potential overflow
we can add the scope API around the problematic code path with the
explanation why it is needed.
Yeah, or maybe we can automate it?  Can the reclaim code check how
much stack space is left and do the right thing automatically?
I am not sure how to do that. Checking for some magic value sounds quite
fragile to me. It also sounds a bit strange to focus only on the reclaim
while other code paths might suffer from the same problem.

What is actually the deepest possible call chain from the slab reclaim
where I stopped? I have tried to follow that path but hit the callback
wall quite early.
 
The reason why I'm nervous is that nojournal mode is not a common
configuration, and "wait until production systems start failing" is
not a strategy that I or many SRE-types find.... comforting.
I understand that but I would be much more happier if we did the
decision based on the actual data rather than a fear something would
break down.

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help