linux-stable.git/fs/ceph/snap.c, branch linux-3.16.y

ceph: avoid repeatedly adding inode to mdsc->snap_flush_list

2019-05-02T20:41:57+00:00

commit 04242ff3ac0abbaa4362f97781dac268e6c3541a upstream.

Otherwise, mdsc->snap_flush_list may get corrupted.

Signed-off-by: "Yan, Zheng" 
Reviewed-by: Ilya Dryomov 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Ben Hutchings

ceph: introduce global empty snap context

2015-02-17T15:12:01+00:00

commit 97c85a828f36bbfffe9d77b977b65a5872b6cad4 upstream.

Current snaphost code does not properly handle moving inode from one
empty snap realm to another empty snap realm. After changing inode's
snap realm, some dirty pages' snap context can be not equal to inode's
i_head_snap. This can trigger BUG() in ceph_put_wrbuffer_cap_refs()

The fix is introduce a global empty snap context for all empty snap
realm. This avoids triggering the BUG() for filesystem with no snapshot.

Fixes: http://tracker.ceph.com/issues/9928

Signed-off-by: Yan, Zheng 
Reviewed-by: Ilya Dryomov 
Cc: Markus Blank-Burian 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

ceph: use ceph_create_snap_context()

2013-05-02T04:20:09+00:00

Now that we have a library routine to create snap contexts, use it.

This is part of:
    http://tracker.ceph.com/issues/4857

Signed-off-by: Alex Elder 
Reviewed-by: Josh Durgin

ceph: define snap counts as u32 everywhere

2012-07-31T01:15:47+00:00

There are two structures in which a count of snapshots are
maintained:

    struct ceph_snap_context {
	...
        u32 num_snaps;
	...
    }
and
    struct ceph_snap_realm {
	...
        u32 num_prior_parent_snaps;   /*  had prior to parent_since */
	...
        u32 num_snaps;
	...
    }

These fields never take on negative values (e.g., to hold special
meaning), and so are really inherently unsigned.  Furthermore they
take their value from over-the-wire or on-disk formatted 32-bit
values.

So change their definition to have type u32, and change some spots
elsewhere in the code to account for this change.

Signed-off-by: Alex Elder 
Reviewed-by: Josh Durgin

introduce SIZE_MAX

2012-06-01T00:49:26+00:00

ULONG_MAX is often used to check for integer overflow when calculating
allocation size.  While ULONG_MAX happens to work on most systems, there
is no guarantee that `size_t' must be the same size as `long'.

This patch introduces SIZE_MAX, the maximum value of `size_t', to improve
portability and readability for allocation size validation.

Signed-off-by: Xi Wang 
Acked-by: Alex Elder 
Cc: David Airlie 
Cc: Pekka Enberg 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ceph: fix overflow check in build_snap_context()

2012-03-22T15:47:45+00:00

The overflow check for a + n * b should be (n > (ULONG_MAX - a) / b),
rather than (n > ULONG_MAX / b - a).

Signed-off-by: Xi Wang 
Signed-off-by: Sage Weil

ceph: use i_ceph_lock instead of i_lock

2011-12-07T18:46:44+00:00

We have been using i_lock to protect all kinds of data structures in the
ceph_inode_info struct, including lists of inodes that we need to iterate
over while avoiding races with inode destruction.  That requires grabbing
a reference to the inode with the list lock protected, but igrab() now
takes i_lock to check the inode flags.

Changing the list lock ordering would be a painful process.

However, using a ceph-specific i_ceph_lock in the ceph inode instead of
i_lock is a simple mechanical change and avoids the ordering constraints
imposed by igrab().

Reported-by: Amon Ott 
Signed-off-by: Sage Weil

ceph: only queue capsnap if caps are dirty

2011-07-26T18:26:41+00:00

We used to go into this branch if i_wrbuffer_ref_head was non-zero.  This
was an ancient check from before we were careful about dealing with all
kinds of caps (and not just dirty pages).  It is cleaner to only queue a
capsnap if there is an actual dirty cap.  If we are racing with...
something...we will end up here with ci->i_wrbuffer_refs but no dirty
caps.

Reviewed-by: Yehuda Sadeh 
Signed-off-by: Sage Weil

ceph: fix snap writeback when racing with writes

2011-07-26T18:26:31+00:00

There are two problems that come up when we try to queue a capsnap while a
write is in progress:

 - The FILE_WR cap is held, but not yet dirty, so we may queue a capsnap
   with dirty == 0.  That will crash later in __ceph_flush_snaps().  Or
   on the FILE_WR cap if a write is in progress.
 - We may not have i_head_snapc set, which causes problems pretty quickly.
   Look to the snaprealm in this case.

Reviewed-by: Yehuda Sadeh 
Signed-off-by: Sage Weil

ceph: use ihold when we already have an inode ref

2011-06-08T04:34:11+00:00

We should use ihold whenever we already have a stable inode ref, even
when we aren't holding i_lock.  This avoids adding new and unnecessary
locking dependencies.

Signed-off-by: Sage Weil