[Cluster-devel] GFS2: Pre-pull patch posting (fixes)
Hi, Here are a couple of very small, but important, fixes, Steve.
[Cluster-devel] [PATCH 1/2] GFS2: fix potential NULL pointer dereference
From: Michal Nazarewicz min...@mina86.com Commit [e66cf1610: GFS2: Use lockref for glocks] replaced call: atomic_read(gi-gl-gl_ref) == 0 with: __lockref_is_dead(gl-gl_lockref) therefore changing how gl is accessed, from gi-gl to plan gl. However, gl can be a NULL pointer, and so gi-gl needs to be used instead (which is guaranteed not to be NULL because fo the while loop checking that condition). Signed-off-by: Michal Nazarewicz min...@mina86.com Signed-off-by: Steven Whitehouse swhit...@redhat.com diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c index e66a800..c8420f7 100644 --- a/fs/gfs2/glock.c +++ b/fs/gfs2/glock.c @@ -1899,7 +1899,8 @@ static int gfs2_glock_iter_next(struct gfs2_glock_iter *gi) gi-nhash = 0; } /* Skip entries for other sb and dead entries */ - } while (gi-sdp != gi-gl-gl_sbd || __lockref_is_dead(gl-gl_lockref)); + } while (gi-sdp != gi-gl-gl_sbd || +__lockref_is_dead(gi-gl-gl_lockref)); return 0; } -- 1.8.3.1
[Cluster-devel] [PATCH 2/2] GFS2: Fix ref count bug relating to atomic_open
In the case that atomic_open calls finish_no_open() with
the dentry that was supplied to gfs2_atomic_open() an
extra reference count is required. This patch fixes that
issue preventing a bug trap triggering at umount time.
Signed-off-by: Steven Whitehouse swhit...@redhat.com
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 1615df1..7119504 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -1171,8 +1171,11 @@ static int gfs2_atomic_open(struct inode *dir, struct
dentry *dentry,
if (d != NULL)
dentry = d;
if (dentry-d_inode) {
- if (!(*opened FILE_OPENED))
+ if (!(*opened FILE_OPENED)) {
+ if (d == NULL)
+ dget(dentry);
return finish_no_open(file, dentry);
+ }
dput(d);
return 0;
}
--
1.8.3.1
[Cluster-devel] GFS2: Pull request (fixes)
Hi, Please consider pulling the following fixes, Steve. The following changes since commit ea0341e071527d5cec350917b01ab901af09d758: GFS2: Fix ref count bug relating to atomic_open (2013-11-21 18:47:57 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes.git tags/gfs2-fixes for you to fetch changes up to ea0341e071527d5cec350917b01ab901af09d758: GFS2: Fix ref count bug relating to atomic_open (2013-11-21 18:47:57 +) A couple of small, but important bug fixes for GFS2. The first one fixes a possible NULL pointer dereference, and the second one resolves a reference counting issue in one of the lesser used paths through atomic_open. fs/gfs2/glock.c |3 ++- fs/gfs2/inode.c |5 - 2 files changed, 6 insertions(+), 2 deletions(-) signature.asc Description: This is a digitally signed message part
Re: [Cluster-devel] [PATCH 1/2] fence_ipmilan: port fencing agent to fencing library
On 21/11/13 16:48 +0100, Fabio M. Di Nitto wrote: On 11/21/2013 4:16 PM, Ondrej Mular wrote: +PATHS = [/usr/local/bull/NSMasterHW/bin/ipmitool, +/usr/bin/ipmitool, +/usr/sbin/ipmitool, +/bin/ipmitool, +/sbin/ipmitool, +/usr/local/bin/ipmitool, +/usr/local/sbin/ipmitool] this hard-cording it bad. Always use OS define PATH and if really necessary allow user to override with an option (for example: --pathtoipmitool=/usr/local) see, e.g., http://git.engineering.redhat.com/users/jpokorny/clufter/tree/utils.py?id=d37db7470f4e44598af0b91d02221182178677ff#n22 that mimics which standard utility Hope this helps -- Jan
Re: [Cluster-devel] [PATCH 1/2] fence_ipmilan: port fencing agent to fencing library
On 11/22/2013 5:18 PM, Jan Pokorný wrote: On 21/11/13 16:48 +0100, Fabio M. Di Nitto wrote: On 11/21/2013 4:16 PM, Ondrej Mular wrote: +PATHS = [/usr/local/bull/NSMasterHW/bin/ipmitool, +/usr/bin/ipmitool, +/usr/sbin/ipmitool, +/bin/ipmitool, +/sbin/ipmitool, +/usr/local/bin/ipmitool, +/usr/local/sbin/ipmitool] this hard-cording it bad. Always use OS define PATH and if really necessary allow user to override with an option (for example: --pathtoipmitool=/usr/local) see, e.g., http://git.engineering.redhat.com/users/jpokorny/clufter/tree/utils.py?id=d37db7470f4e44598af0b91d02221182178677ff#n22 that mimics which standard utility Hope this helps I´d like to understand why we need a search path in the first place tho and we can´t just rely on shell hitting the right tool :) Fabio
