glusterfs.git/xlators/protocol/server/src/server-resolve.c, branch v5.0rc0

Land part 2 of clang-format changes

2018-09-12T12:22:45+00:00

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu

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

2018-09-05T09:23:26+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.

Fixes: bz#1625095

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

server/resolver: don't trust inode-table for RESOLVE_NOT

2018-04-30T04:58:08+00:00

There have been known races between fops which add a dentry (like
lookup, create, mknod etc) and fops that remove a dentry (like rename,
unlink, rmdir etc) due to which stale dentries are left out in inode
table even though the dentry doesn't exist on backend. For eg.,
consider a lookup (parent/bname) and unlink (parent/bname) racing in
the following order:

* lookup hits storage/posix and finds that dentry exists
* unlink removes the dentry on storage/posix
* unlink reaches protocol/server where the dentry (parent/bname) is
  unlinked from the inode
* lookup reaches protocol/server and creates a dentry (parent/bname)
  on the inode

Now we've a stale dentry (parent/bname) associated with the inode in
itable. This situation is bad for fops like link, create etc which
invoke resolver with type RESOLVE_NOT. These fops fail with EEXIST
even though there is no such dentry on backend fs. This issue can be
solved in two ways:

* Enable "dentry fop serializer" xlator [1].
  # gluster volume set features.sdfs on

* Make sure resolver does a lookup on backend when it finds a dentry
  in itable and validates the state of itable.
   - If a dentry is not found, unlink those stale dentries from itable
     and continue with fop
   - If dentry is found, fail the fop with EEXIST

This patch implements second solution as sdfs is not enabled by
default in brick xlator stack. Once sdfs is enabled by default, this
patch can be reverted.

[1] https://github.com/gluster/glusterfs/issues/397

Change-Id: Ia8bb0cf97f97cb0e72639bce8aadb0f6d3f4a34a
updates: bz#1543279
BUG: 1543279
Signed-off-by: Raghavendra G

protocol/server: fix unused variable warnings/errors

2016-08-27T11:17:49+00:00

http://review.gluster.org/14085 fixes a/the "leak" - via the
generated rpc/xdr headers - of pragmas that mask these warnings.

However 14085 won't pass the smoke test until all the warnings are
fixed.

Change-Id: I5a48055c4b0a4a07dd511ad4f2e9ef823b9c60b2
BUG: 1369124
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/15255
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra G

libglusterfs: Negate all but O_DIRECT flag if present on anon fds

2016-06-10T05:05:46+00:00

This is to prevent any unforeseen problems that might arise due to
writevs and readvs being wound with @flag parameter containing
O_TRUNC or O_APPEND especially wrt translators like sharding and ec
where O_TRUNC write or O_APPEND write on individual shards/fragments
is not the same as O_TRUNC write or O_APPEND write as expected by the
application.

Change-Id: I9e5206a6ce2b1b70df61ff23b1c961cf25bf7ff9
BUG: 1342171
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/14665
Reviewed-by: Pranith Kumar Karampuri 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Tested-by: Gluster Build System 
NetBSD-regression: NetBSD Build System

core, shard: Make shards inherit main file's O_DIRECT flag if present

2016-06-07T07:19:26+00:00

If the application opens a file with O_DIRECT, the shards'
anon fds would also need to inherit the flag. Towards this,
shard xl would be passing the odirect flag in the @flags parameter
to the WRITEV fop. This will be used in anon fd resolution
and subsequent opening by posix xl.

Change-Id: Iddb75c9ed14ce5a8c5d2128ad09b749f46e3b0c2
BUG: 1342171
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/14191
Tested-by: Pranith Kumar Karampuri 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

server: send lookup on root inode when itable is created

2016-03-30T19:39:42+00:00

 * xlators like quota, marker, posix_acl can cause problems
   if inode-ctx are not created.
   sometime these xlarors may not get lookup on root inode
   with below cases
   1) client may not send lookup on root inode (like NSR leader)
   2) if the xlators on one of the bricks are not up,
      and client sending lookup during this time: brick
      can miss the lookup
   It is always better to make sure that there is one lookup
   on root. So send a first lookup when the inode table is created

 * When sending lookup on root, new inode is created, we need to
   use itable->root instead

Change-Id: Iff2eeaa1a89795328833a7761789ef588f11218f
BUG: 1320818
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/13837
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Jeff Darcy

protocol/server : porting missing gf_log's to gf_msg

2015-08-26T12:08:24+00:00

Change-Id: I8818931fafea3c013551a5de23a9f77c81164841
BUG: 1252808
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/11895
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created

2015-08-11T04:22:09+00:00

This test sets the lru limit of the inode table to 1 and checks if inode forgets
and resolve cause any problem with bit-rot xattrs (especially bad-file xattr).

Change-Id: I1fa25fa2d31dda8d26e8192562e896e5bddd0381
BUG: 1244613
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11718
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar

protocol/server: use different dict for resolving

2015-07-16T06:13:46+00:00

protocol/server has to resolve the inode before continuing with any fop coming
from the clients. For resolving it, server xlator was using the same dict
associated with the fop. It causes problems in some situations.

If a directory's inode was forgotten because of lru limit being exceeded, then
when a create fop comes for an entry within that directory, server tries to
resolve it. But since the parent directory's inode is not found in the inode
table, it tries to do a hard resolve by doing a lookup on the parent gfid.

If any xlator below server wants to get some extended attributes whenever
lookup comes, then they set the new keys in the same dict that came along with
the create fop. Now, the lookup of the parent succeeds and the create fop
proceeds with the same dict (with extra keys present). posix xlaror creates
those xattrs that are present in the dict. Thus the xattrs which were not to
be present by default are also set as part of create. (Ex: bit-rot related
xattrs such as bad-file, version and sign xattrs)

Change-Id: I4bdad175a1d7a04a3aa36073667c556d6c260263
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11661
Reviewed-by: Vijaikumar Mallikarjuna 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G