Hi,
I have posted the previous version here [1]. There are no real changes
in the implementation since then. I've just added "lockdep: teach
lockdep about memalloc_noio_save" from Nikolay which is a lockdep bugfix
developed independently but "mm: introduce memalloc_nofs_{save,restore}
API" depends on it so I added it here. Then I've rebased the series on
top of 4.11-rc1 which contains sched.h split up which required to add
sched/mm.h include.
There didn't seem to be any real objections and so I think we should go
and finally merge this - ideally in this release cycle as it doesn't
really introduce any functional changes. Those were separated out and
will be posted later. The risk of regressions should really be small
because we do not remove any real GFP_NOFS users yet.
Diffstat says
fs/jbd2/journal.c | 8 ++++++++
fs/jbd2/transaction.c | 12 ++++++++++++
fs/xfs/kmem.c | 12 ++++++------
fs/xfs/kmem.h | 2 +-
fs/xfs/libxfs/xfs_btree.c | 2 +-
fs/xfs/xfs_aops.c | 6 +++---
fs/xfs/xfs_buf.c | 8 ++++----
fs/xfs/xfs_trans.c | 12 ++++++------
include/linux/gfp.h | 18 +++++++++++++++++-
include/linux/jbd2.h | 2 ++
include/linux/sched.h | 6 +++---
include/linux/sched/mm.h | 26 +++++++++++++++++++++++---
kernel/locking/lockdep.c | 11 +++++++++--
lib/radix-tree.c | 2 ++
mm/page_alloc.c | 10 ++++++----
mm/vmscan.c | 6 +++---
16 files changed, 106 insertions(+), 37 deletions(-)
Shortlog:
Michal Hocko (6):
lockdep: allow to disable reclaim lockup detection
xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS
mm: introduce memalloc_nofs_{save,restore} API
xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*
jbd2: mark the transaction context with the scope GFP_NOFS context
jbd2: make the whole kjournald2 kthread NOFS safe
Nikolay Borisov (1):
lockdep: teach lockdep about memalloc_noio_save
[1] http://lkml.kernel.org/r/20170206140718.16222-1-mhocko@xxxxxxxxxx
[2] http://lkml.kernel.org/r/20170117030118.727jqyamjhojzajb@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
