From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 0/4] GFS2: Enforce gl_object integrity
Date: Tue, 18 Jul 2017 13:23:01 -0500 [thread overview]
Message-ID: <20170718182305.27798-1-rpeterso@redhat.com> (raw)
This is a four patch set that tries to ensure the integrity of the
glock field gl_object. This is vital to guard against metadata corruption
because the glock ops (glops.c) often use gl_object as a starting point.
For example, when you lock an inode glock, inode_go_lock sets
ip = gl_object and makes decisions from that value. Function
inode_go_sync does a similar thing.
The problem is that gfs2 was sometimes setting and clearing gl_object
without any kind of locking. There were other places where it failed
to clear the value in error cases. Processes would indescriminately
overwrite the values of other processes, causing chaos.
The first patch introduces a new helper to clear gl_object.
This complements the function recently added to set gl_object.
The second patch moves the setting of gl_object after the block type
check in function gfs2_inode_lookup. This prevents corruption that
sometimes occurred when inode blocks were deleted and reused.
The third patch adds calls to clear gl_object if gfs2_create_inode
fails so residual values aren't left over in the glock.
The fourth patch adds calls to clear gl_object during the inode evict
process. The value must be freed prior to actually freeing the block
in the bitmap because the block could be reused for a different inode,
but the glock can remain in core. If the object is evicted but not
deleted, it must also be cleared, but in a different code path.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
---
Bob Peterson (4):
GFS2: Introduce helper for clearing gl_object
GFS2: Set gl_object in inode lookup only after block type check
GFS2: Clear gl_object if gfs2_create_inode fails
GFS2: Clear gl_object when deleting an inode in gfs2_delete_inode
fs/gfs2/glock.h | 34 ++++++++++++++++++++++++++++++++++
fs/gfs2/inode.c | 11 +++++++----
fs/gfs2/super.c | 15 ++++++++++++---
3 files changed, 53 insertions(+), 7 deletions(-)
--
2.13.3
next reply other threads:[~2017-07-18 18:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 18:23 Bob Peterson [this message]
2017-07-18 18:23 ` [Cluster-devel] [PATCH 1/4] GFS2: Introduce helper for clearing gl_object Bob Peterson
2017-08-30 11:15 ` Andreas Gruenbacher
2017-08-30 13:18 ` Bob Peterson
2017-07-18 18:23 ` [Cluster-devel] [PATCH 2/4] GFS2: Set gl_object in inode lookup only after block type check Bob Peterson
2017-07-18 18:53 ` Bob Peterson
2017-07-18 18:23 ` [Cluster-devel] [PATCH 3/4] GFS2: Clear gl_object if gfs2_create_inode fails Bob Peterson
2017-07-18 18:23 ` [Cluster-devel] [PATCH 4/4] GFS2: Clear gl_object when deleting an inode in gfs2_delete_inode Bob Peterson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170718182305.27798-1-rpeterso@redhat.com \
--to=rpeterso@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).