On Mon, 6 Mar 2017 14:14:05 +0100 Michal Hocko wrote:
> From: Michal Hocko
>
> GFP_NOFS context is used for the following 5 reasons currently
> - to prevent from deadlocks when the lock held by the allocation
> context would be needed during the memory reclaim
> - to preven
- Original Message -
| Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
| the entire struct lm_lockname instead of its individual fields. On some
| architectures, struct lm_lockname contains a hole of uninitialized
| memory due to alignment rules, which now leads to
Hi,
On 06/03/17 16:55, Andreas Gruenbacher wrote:
On Mon, Mar 6, 2017 at 4:15 PM, Steven Whitehouse wrote:
On 06/03/17 14:33, Andreas Gruenbacher wrote:
Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
the entire struct lm_lockname instead of its individual fields. O
On Mon, Mar 6, 2017 at 4:15 PM, Steven Whitehouse wrote:
> On 06/03/17 14:33, Andreas Gruenbacher wrote:
>>
>> Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
>> the entire struct lm_lockname instead of its individual fields. On some
>> architectures, struct lm_lockname c
Hi,
On 06/03/17 14:33, Andreas Gruenbacher wrote:
Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
the entire struct lm_lockname instead of its individual fields. On some
architectures, struct lm_lockname contains a hole of uninitialized
memory due to alignment rules, w
- Original Message -
| Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
| the entire struct lm_lockname instead of its individual fields. On some
| architectures, struct lm_lockname contains a hole of uninitialized
| memory due to alignment rules, which now leads to
Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
the entire struct lm_lockname instead of its individual fields. On some
architectures, struct lm_lockname contains a hole of uninitialized
memory due to alignment rules, which now leads to incorrect hash values.
Get rid of th
Both functions are identical except for the seq_operations used.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/glock.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 339deb4..2cbc11b 100644
--- a/fs/gfs2/gl
Function rhashtable_walk_init is deprecated.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/glock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index ec0848f..339deb4 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1932,7 +1932,7 @
From: Michal Hocko
kjournald2 is central to the transaction commit processing. As such any
potential allocation from this kernel thread has to be GFP_NOFS. Make
sure to mark the whole kernel thread GFP_NOFS by the memalloc_nofs_save.
Suggested-by: Jan Kara
Reviewed-by: Jan Kara
Signed-off-by:
From: Michal Hocko
The current implementation of the reclaim lockup detection can lead to
false positives and those even happen and usually lead to tweak the
code to silence the lockdep by using GFP_NOFS even though the context
can use __GFP_FS just fine. See
http://lkml.kernel.org/r/201605120803
From: Michal Hocko
xfs has defined PF_FSTRANS to declare a scope GFP_NOFS semantic quite
some time ago. We would like to make this concept more generic and use
it for other filesystems as well. Let's start by giving the flag a
more generic name PF_MEMALLOC_NOFS which is in line with an exiting
PF
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
From: Michal Hocko
GFP_NOFS context is used for the following 5 reasons currently
- to prevent from deadlocks when the lock held by the allocation
context would be needed during the memory reclaim
- to prevent from stack overflows during the reclaim because
the
From: Michal Hocko
now that we have memalloc_nofs_{save,restore} api we can mark the whole
transaction context as implicitly GFP_NOFS. All allocations will
automatically inherit GFP_NOFS this way. This means that we do not have
to mark any of those requests with GFP_NOFS and moreover all the
ext4
From: Nikolay Borisov
Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
during memory allocation") added the memalloc_noio_(save|restore) functions
to enable people to modify the MM behavior by disabling I/O during memory
allocation. This was further extended in Fixes: 934f
From: Michal Hocko
kmem_zalloc_large and _xfs_buf_map_pages use memalloc_noio_{save,restore}
API to prevent from reclaim recursion into the fs because vmalloc can
invoke unconditional GFP_KERNEL allocations and these functions might be
called from the NOFS contexts. The memalloc_noio_save will en
Hi,
Acked-by: Steven Whitehouse
Steve.
On 03/03/17 17:42, Bob Peterson wrote:
Hi,
When the GFS2 file system withdraws due to metadata corruption, it
often has outstanding transactions in the journal and delayed work
queued for its glocks. This patch adds some new checks for a
withdrawn file
On Tue 17-01-17 08:54:50, Michal Hocko wrote:
> On Mon 16-01-17 22:01:18, Theodore Ts'o wrote:
> > On Fri, Jan 06, 2017 at 03:11:06PM +0100, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because
> > > sb_getblk_gfp is not rea
19 matches
Mail list logo
