On Wed, Apr 16, 2014 at 03:52:30PM +1000, NeilBrown wrote:
> So something like this? I put that in to my testing instead.
Something like this, yes... And TBH I would prefer the same approach
elsewhere - this kind of hidden state makes it hard to do any kind of
analysis.
Put it that way - the s
On Wed, 16 Apr 2014 05:46:18 +0100 Al Viro wrote:
> On Wed, Apr 16, 2014 at 02:03:37PM +1000, NeilBrown wrote:
> > namespace_sem can be taken while various i_mutex locks are held, so we
> > need to avoid reclaim from blocking on an FS (particularly loop-back
> > NFS).
>
> I would really prefer t
On Wed, Apr 16, 2014 at 02:03:37PM +1000, NeilBrown wrote:
> namespace_sem can be taken while various i_mutex locks are held, so we
> need to avoid reclaim from blocking on an FS (particularly loop-back
> NFS).
I would really prefer to deal with that differently - by explicit change of
gfp_t argum
namespace_sem can be taken while various i_mutex locks are held, so we
need to avoid reclaim from blocking on an FS (particularly loop-back
NFS).
A memory allocation happens under namespace_sem at least in:
[] kmem_cache_alloc+0x4f/0x290
[] alloc_vfsmnt+0x1f/0x1d0
[] clone_mnt+0x2a/0x310
[] copy_
4 matches
Mail list logo
