glusterfs.git/xlators/features, branch v5.5

features/shard: Ref shard inode while adding to fsync list

2019-02-04T15:07:46+00:00

PROBLEM:

Lot of the earlier changes in the management of shards in lru, fsync
lists assumed that if a given shard exists in fsync list, it must be
part of lru list as well. This was found to be not true.

Consider this - a file is FALLOCATE'd to a size which would make the
number of participant shards to be greater than the lru list size.
In this case, some of the resolved shards that are to participate in
this fop will be evicted from lru list to give way to the rest of the
shards. And once FALLOCATE completes, these shards are added to fsync
list but without a ref. After the fop completes, these shard inodes
are unref'd and destroyed while their inode ctxs are still part of
fsync list. Now when an FSYNC is called on the base file and the
fsync-list traversed, the client crashes due to illegal memory access.

FIX:

Hold a ref on the shard inode when adding to fsync list as well.
And unref under following conditions:
1. when the shard is evicted from lru list
2. when the base file is fsync'd
3. when the shards are deleted.

Change-Id: Iab460667d091b8388322f59b6cb27ce69299b1b2
fixes: bz#1669382
Signed-off-by: Krutika Dhananjay 
(cherry picked from commit 72922c1fd69191b220f79905a23395c3a87f86ce)

features/shard: Fix launch of multiple synctasks for background deletion

2019-01-15T04:57:11+00:00

PROBLEM:

When multiple sharded files are deleted in quick succession, multiple
issues were observed:
1. misleading logs corresponding to a sharded file where while one log
   message said the shards corresponding to the file were deleted
   successfully, this was followed by multiple logs suggesting the very
   same operation failed. This was because of multiple synctasks
   attempting to clean up shards of the same file and only one of them
   succeeding (the one that gets ENTRYLK successfully), and the rest of
   them logging failure.

2. multiple synctasks to do background deletion would be launched, one
   for each deleted file but all of them could readdir entries from
   .remove_me at the same time could potentially contend for ENTRYLK on
   .shard for each of the entry names. This is undesirable and wasteful.

FIX:
Background deletion will now follow a state machine. In the event that
there are multiple attempts to launch synctask for background deletion,
one for each file deleted, only the first task is launched. And if while
this task is doing the cleanup, more attempts are made to delete other
files, the state of the synctask is adjusted so that it restarts the
crawl even after reaching end-of-directory to pick up any files it may
have missed in the previous iteration.

This patch also fixes uninitialized lk-owner during syncop_entrylk()
which was leading to multiple background deletion synctasks entering
the critical section at the same time and leading to illegal memory access
of base inode in the second syntcask after it was destroyed post shard deletion
by the first synctask.

Change-Id: Ib33773d27fb4be463c7a8a5a6a4b63689705324e
updates: bz#1665803
Signed-off-by: Krutika Dhananjay 
(cherry picked from commit c0c2022e7d7097e96270a74f37813eda0c4e6339)

features/shard: Assign fop id during background deletion to prevent excessive logging

2019-01-14T06:41:20+00:00

... of the kind

"[2018-12-26 05:22:44.195019] E [MSGID: 133010]
[shard.c:2253:shard_common_lookup_shards_cbk] 0-volume1-shard: Lookup
on shard 785 failed. Base file gfid = cd938e64-bf06-476f-a5d4-d580a0d37416
[No such file or directory]"

shard_common_lookup_shards_cbk() has a specific check to ignore ENOENT error without
logging them during specific fops. But because background deletion is done in a new
frame (with local->fop being GF_FOP_NULL), the ENOENT check is skipped and the
absence of shards gets logged everytime.

To fix this, local->fop is initialized to GF_FOP_UNLINK during background deletion.

Change-Id: I0ca8d3b3bfbcd354b4a555eee520eb0479bcda35
updates: bz#1665803
Signed-off-by: Krutika Dhananjay 
(cherry picked from commit aa28fe32364e39981981d18c784e7f396d56153f)

leases: Reset lease_ctx->timer post deletion

2019-01-09T15:34:21+00:00

To avoid use_after_free, reset lease_ctx->timer back to NULL
after the structure has been freed.

Change-Id: Icd213ec809b8af934afdb519c335a4680a1d6cdc
updates: bz#1651323
Signed-off-by: Soumya Koduri 
(cherry picked from commit a9b0003c717087ff168bc143c70559162e53e0d5)

shard: prevent segfault in shard_unlink_block_inode()

2018-12-20T14:19:55+00:00

gluster-blockd sometimes segfaults with the following backtrace: 

    Core was generated by `/usr/sbin/gluster-blockd --glfs-lru-count 5 --log-level INFO'.
    Program terminated with signal 11, Segmentation fault.
    #0  0x00007fbb9cd639b9 in shard_unlink_block_inode (local=local@entry=0x7fbb80000a78, shard_block_num=) at shard.c:2929
    2929	            base_ictx->fsync_count--;
    (gdb) bt
    #0  0x00007fbb9cd639b9 in shard_unlink_block_inode (local=local@entry=0x7fbb80000a78, shard_block_num=) at shard.c:2929
    #1  0x00007fbb9cd64311 in shard_unlink_shards_do_cbk (frame=frame@entry=0x7fbb9010a768, cookie=, this=, op_ret=, op_errno=, preparent=preparent@entry=0x7fbb7470dcf8, 
        postparent=postparent@entry=0x7fbb7470dd90, xdata=xdata@entry=0x0) at shard.c:2987

A fix for this has already been provided through a Converity report.

Backport of:

> Change-Id: Ic5d302a5e32d375acf8adc412763ab94e6dabc3d
> Signed-off-by: Sunny Kumar 
> (cherry picked from commit 145e180517054626d07892219fdee689b703c218)

Change-Id: I699a039e9c5115eb3376190dd8014427d12a293b
Updates: bz#1659563
Signed-off-by: Niels de Vos

features/bitrot: compare the signature with proper length

2018-12-12T12:59:18+00:00

* The scrubber was comparing the checksum of the file that it
  calculated (by reading the file) with the on disk signature
  (stored via xattr) wrongly. It was using strlen to calculate
  the signature, while the actual length of the signature is
  given by the brick. Just use the actual length that the brick
  provides instead of trying to calculate the signature length via
  strlen API.

* In posix, gfid2path was using the same string that contains the
  list of all the xattrs of file to save the value of the gfid2path
  xattr as well. This causes confusion when gfid2path xattr is queried
  by scrubber for getting the actual path of a corrupted file. Use
  separate string to fetch the value of the xattr instead of the string
  that contains the list of xattrs.

Backport of:
 > Patch: https://review.gluster.org/21752/
 > BUG: 1654805
 > Change-Id: I2d664ab524d2b312233476cb35863dde3122e9a9
(cherry picked from commit f77fb6d568616592ab25501c402c140d15235ca9)
 
Change-Id: I2d664ab524d2b312233476cb35863dde3122e9a9
fixes: bz#1654370
Signed-off-by: Raghavendra Bhat

leases: Do not conflict with internal fops

2018-12-12T12:54:48+00:00

Internal fops (with frame->root->pid < 0) are used to heal
or move data and maintains data integrity. That is they do not
modify client data which holds the lease. Hence no need to recall
Lease for such fops.

Note: Like for locks, we would need rebalance and self-heal
daemon process to heal lease state as well.

Change-Id: I8988693fef8d00e17c19dcc842e2238f9eb5ab48
updates: bz#1651323
Signed-off-by: Soumya Koduri 
(cherry picked from commit 080aa5b9e9d998552e23f7c33aed3afb0ca93c34)

lease: Treat unlk request as noop if lease not found

2018-12-12T12:53:10+00:00

When the glusterfs server recalls the lease, it expects
client to flush data and unlock the lease. If not it sets
a timer (starting from the time it sends RECALL request) and post
timeout, it revokes it.

Here we could have a race where in client did send UNLK
lease request but because of network delay it may have reached
after server revokes it. To handle such situations, treat
such requests as noop and return sucesss.

Change-Id: I166402d10273f4f115ff04030ecbc14676a01663
updates: bz#1651323
Signed-off-by: Soumya Koduri 
(cherry picked from commit c2e758b54d8a3f778e3e63db0000bb8b63de9b25)

leases: Fix incorrect inode_ref/unrefs

2018-11-29T15:34:57+00:00

From testing & code-reading, found couple of places where
we incorrectly unref the inode resulting in use_after_free
crash or ref leaks. This patch addresses couple of them.

a) When we try to grant the very first lease for a inode,
inode_ref is taken in __add_lease. This ref should be active
till all the leases granted to that inode are released (i.e,
till lease_cnt > 0). In addition even after lease_cnt becomes '0',
the inode should be active till all the blocked fops are resumed.

Hence release this ref, after resuming all those fops. To avoid
granting new leases while resuming those fops, defined a new boolean
(blocked_fops_resuming) to flag it in the lease_ctx.

b) 'new_lease_inode' which creates new lease_inode_entry and
takes ref on inode, is used while adding that entry to
client_list and recall_list.

Use its counter function '__destroy_lease_inode' which does unref
while removing those entries from those lists.

c) inode ref is also taken when added to timer->data. Unref the same
after processing timer->data.

Change-Id: Ie77c78ff4a971e0d9a66178597fb34faf39205fb
updates: bz#1651323
Signed-off-by: Soumya Koduri 
(cherry picked from commit b7aec05aa965202ab73120acf0da4c32fe0cf16c)

all: fix the format string exceptions

2018-11-09T14:03:02+00:00

Currently, there are possibilities in few places, where a user-controlled
(like filename, program parameter etc) string can be passed as 'fmt' for
printf(), which can lead to segfault, if the user's string contains '%s',
'%d' in it.

While fixing it, makes sense to make the explicit check for such issues
across the codebase, by making the format call properly.

Fixes: CVE-2018-14661

Fixes: bz#1647666
Change-Id: Ib547293f2d9eb618594cbff0df3b9c800e88bde4
Signed-off-by: Amar Tumballi