glusterfs.git/xlators, branch release-3.12

afr: prevent winding inodelks twice for arbiter volumes

2018-10-12T04:09:30+00:00

Backport of https://review.gluster.org/#/c/glusterfs/+/21380/

Problem:
In an arbiter volume, if there is a pending data heal of a file only on
arbiter brick, self-heal takes inodelks twice due to a code-bug but unlocks
it only once, leaving behind a stale lock on the brick. This causes
the next write to the file to hang.

Fix:
Fix the code-bug to take lock only once. This bug was introduced master
with commit eb472d82a083883335bc494b87ea175ac43471ff

Thanks to  Pranith Kumar K  for finding the RCA.

fixes: bz#1637989
Change-Id: I15ad969e10a6a3c4bd255e2948b6be6dcddc61e1
BUG: 1637989
Signed-off-by: Ravishankar N

cluster/afr: Delegate metadata heal with pending xattrs to SHD

2018-10-12T04:08:57+00:00

Problem:
When metadata-self-heal is triggered on the mount, it blocks
lookup until metadata-self-heal completes. But that can lead
to hangs when lot of clients are accessing a directory which
needs metadata heal and all of them trigger heals waiting
for other clients to complete heal.

Fix:
Only when the heal is needed but the pending xattrs are not set,
trigger metadata heal that could block lookup. This is the only
case where different clients may give different metadata to the
clients without heals, which should be avoided.

Updates bz#1625588
Change-Id: I6089e9fda0770a83fb287941b229c882711f4e66
Signed-off-by: Pranith Kumar K

cluster/afr: Delegate name-heal when possible

2018-10-12T04:08:32+00:00

Problem:
When name-self-heal is triggered on the mount, it blocks
lookup until name-self-heal completes. But that can lead
to hangs when lot of clients are accessing a directory which
needs name heal and all of them trigger heals waiting
for other clients to complete heal.

Fix:
When a name-heal is needed but quorum number of names have the
file and pending xattrs exist on the parent, then better to
delegate the heal to SHD which will be completed as part of
entry-heal of the parent directory. We could also do the same
for quorum-number of names not present but we don't have
any known use-case where this is a frequent occurrence so
not changing that part at the moment. When there is a gfid
mismatch or missing gfid it is important to complete the heal
so that next rename doesn't assume everything is fine and
perform a rename etc

fixes bz#1625588
Change-Id: I8b002c85dffc6eb6f2833e742684a233daefeb2c
Signed-off-by: Pranith Kumar K

dht: Fill first_up_subvol before use in dht_opendir

2018-10-10T05:22:52+00:00

Reported by: Sam McLeod

Change-Id: Ic8f9b46b173796afd70aff1042834b03ac3e80b2
BUG: 1512371
Signed-off-by: Poornima G

afr: fix incorrect reporting of directory split-brain

2018-10-10T05:20:42+00:00

Backport of https://review.gluster.org/#/c/glusterfs/+/21135/

Problem:
When a directory has dirty xattrs due to failed post-ops or when
replace/reset brick is performed, AFR does a conservative merge as
expected, but heal-info reports it as split-brain because there are no
clear sources.

Fix:
Modify pending flag to contain information about pending heals and
split-brains. For directories, if spit-brain flag is not set,just show
them as needing heal and not being in split-brain.

Fixes: bz#1633625
Change-Id: I09ef821f6887c87d315ae99e6b1de05103cd9383
BUG: 1633625
Signed-off-by: Ravishankar N

glusterd: volume inode/fd status broken with brick mux

2018-09-18T06:54:52+00:00

        backport of:https://review.gluster.org/#/c/19846/6

Problem:
The values for inode/fd was populated from the ctx received
from the server xlator.
Without brickmux, every brick from a volume belonged to a
single brick from the volume.
So searching the server and populating it worked.

With brickmux, a number of bricks can be confined to a single
process. These bricks can be from different volumes too (if
we use the max-bricks-per-process option).
If they are from different volumes, using the server xlator
to populate causes problem.

Fix:
Use the brick to validate and populate the inode/fd status.

>Signed-off-by: hari gowtham 
>Change-Id: I2543fa5397ea095f8338b518460037bba3dfdbfd
>fixes: bz#1566067

Change-Id: I2543fa5397ea095f8338b518460037bba3dfdbfd
BUG: 1569336
fixes: bz#1569336
Signed-off-by: hari gowtham

protocol: don't use alloca

2018-09-06T15:55:43+00:00

current implementation of alloca can cause issues when strings larger
than the allocated buffer is passed to the xdr. Hence it makes sense
to allow XDR decode functions to deal with memory allocations, which
we can free later.

BUG: 1625654
Change-Id: I3a05553f5702de9575c244649ca0e5ac9abaac94
Signed-off-by: Amar Tumballi

posix: disable open/read/write on special files

2018-09-06T15:55:03+00:00

In the file system, the responsibility w.r.to the block and char device
files is related to only support for 'creating' them (using mknod(2)).

Once the device files are created, the read/write syscalls for the specific
devices are handled by the device driver registered for the specific major
number, and depending on the minor number, it knows where to read from.
Hence, we are at risk of reading contents from devices which are handled
by the host kernel on server nodes.

By disabling open/read/write on the device file, we would be safe with
the bypass one can achieve from client side (using gfapi)

BUG: 1625648

Change-Id: I48c776b0af1cbd2a5240862826d3d8918601e47f
Signed-off-by: Amar Tumballi

io-stats: dump io-stats info in /var/run/gluster

2018-09-06T15:54:50+00:00

It wouldn't make sense to allow iostats file to be written in
*any* directory. While the formating makes sure we try to append
io-stats-name for the file, so overwriting existing file is slim,
but in any case it makes sense to restrict dumping to one directory.

Below are the sample commands, and files created for the corresponding
values:

 $ setfattr -n trusted.io-stats-dump -v file-for-dump $M0

In this case, the file would be in /var/run/gluster/file-for-dump

 $ setfattr -n trusted.io-stats-dump -v /dir1/dir2/file-for-dump $M0

In this case, then the dump file is in /var/run/gluster/dir1-dir2-file-for-dump

Note that the value passed for this virtual xattr would be treated as a
file, and even if the value has '/' in it, it would be changed to '-'
for sanity.

BUG: 1625660

Change-Id: Id9ae6a40a190b8937c51662e6e1c2a0f6c86a0e0
Signed-off-by: Amar Tumballi

server-protocol: don't allow '../' path in 'name'

2018-09-06T15:54:16+00:00

This will prevent any arbitrary file creation through glusterfs
by modifying the client bits.

Also check for the similar flaw inside posix too, so we prevent any
changes in layers in-between.

BUG: 1625664
Signed-off-by: Amar Tumballi 
Change-Id: Id9fe0ef6e86459e8ed85ab947d977f058c5ae06e