Remove redundant state/share conflict tests

The old code did THREE share conflict checks on every NFS v4 open...

The first check (which is the one retained) is a call to
state_share_check_conflict after doing a permission check for open (to
dispose of share conflicts quickly).

The second check was from state_add_impl. This check is actually insidious
because EVERY new state, whether it is a share reservation or not is checked
for conflict with every other stateid on the file. Of course the only ACTUAL
conflicts checked are between share reservations...

The final check was from either state_share_add or state_share_upgrade.

Note that we do NOT need to check differently on upgrade due to this text in RFC
3530bis in Section 9.9. Share Reservations:

This checking of share reservations on OPEN is done with no exception
for an existing OPEN for the same open-owner.

I also added a todo comment indicating that the anonymous IO temporary share
implemented with state_share_anonymous_io_start and
state_share_anonymous_io_done needs to distinguish v3 and v4 anonymouse I/O.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Acked-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Use state_share_anonymous_io_start for anonymous I/O conflicts with shares

There are several sources of anonymous I/O (basically any I/O not associated
with an NFS v4 stateid). Note that SETATTR of size is considered write I/O.

Any I/O with an NFS v4 special stateid.

Any NFS v3 I/O.

The all-ones NFS v4 special stateid allows READ operations to bypass share deny
read. WRITE and SETATTR(SIZE) operations are blocked by a share deny write.

With the all-zeros NFS v4 special stateid, READ is blocked by share deny read
and WRITE or SETATTR(SIZE) is blocked by share deny write.

NSF v3 READ operations are not blocked by share deny read, but NFS v3 WRITE
and SETATTR(SIZE) operations are blocked by share deny write (so this is the
same behavior as using the NFS v4 all-ones special stateid).

Note that since NFS v3 offers share reservations via NLM_SHARE, but there is
nothing like a stateid to tie the I/O to the share reservation, we must be
generous and enforce only FS v4 share deny modes against NFS v3 I/O. NLM_SHARE
with deny modes will only block NFS v4 anonymous I/O. When processing an
NFS v4 OPEN or an NLM_SHARE, deny modes always block new share reservations
with incompatible access modes. Thus, in effect, NLM_SHARE deny modes are
just advisory locks.

This behavior may be refined in the future if NFS v3 I/O is tied to an
NLM_SHARE (for example, we could assume that any I/O coming from the same
host as an applicable NLM_SHARE is using the share, otherwise, we could
conclude such I/O should conflict with any share deny modes.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Acked-by: Malahal Naineni <malahal@us.ibm.com>
Fix a lock ABBA problem in cache_inode_lru_cleanup_try_push

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Acked-by: Malahal Naineni <malahal@us.ibm.com>
Acked-by: Matt Benjamin <matt@linuxbox.com>
Backout attempt to detect sandbox builds with ganesha.nfsd -v option

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Acked-by: Malahal Naineni <malahal@us.ibm.com>