Remove handling for a nonexistant case (status && !-EAGAIN).
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

If this loses any backchannel, make sure we have a chance to notice that
and set the sequence flags.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This makes sure we set the sequence flag when necessary.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Implement the SEQ4_STATUS_CB_PATH_DOWN flag.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Distinguish between when the callback channel is known to be down, and
when it is not yet confirmed.  This will be useful in the 4.1 case.

Also, we don't seem to be using the fact that this field is atomic.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

This allows us to reuse the xprt associated with a server connection if
one has already been set up.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Multiple backchannels can share the same tcp connection; from rfc 5661 section
2.10.3.1:

	A connection's association with a session is not exclusive.  A
	connection associated with the channel(s) of one session may be
	simultaneously associated with the channel(s) of other sessions
	including sessions associated with other client IDs.

However, multiple backchannels share a connection, they must all share
the same xid stream (hence the same rpc_xprt); the only way we have to
match replies with calls at the rpc layer is using the xid.

So, keep the rpc_xprt around as long as the connection lasts, in case
we're asked to use the connection as a backchannel again.

Requests to create new backchannel clients over a given server
connection should results in creating new clients that reuse the
existing rpc_xprt.

But to start, just reject attempts to associate multiple rpc_xprt's with
the same underlying bc_xprt.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This seems obviously transport-level information even if it's currently
used only by the server socket code.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Now that we have a list of connections to choose from, we can teach the
callback code to just pick a suitable connection and use that, instead
of insisting on forever using the connection that the first
create_session was sent with.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Basic xdr and processing for BIND_CONN_TO_SESSION.  This adds a
connection to the list of connections associated with a session.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We want to traverse this from the callback code.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

I made a slight mess of Documentation/filesystems/Locking; resolve
conflicts with upstream before fixing it up.

I thought I'd removed the last user of this, but missed
fs/locks.c:lease_release_private_callback().  Thanks to Christoph for
pointing this out.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

when callback is generated in NFSv4 server, it doesn't set the source
address. When an alias IP is utilized on NFSv4 server and suppose the
client is accessing via that alias IP (e.g. eth0:0), the client invokes
the callback to the IP address that is set on the original device (e.g.
eth0). This behavior results in timeout of xprt.
The patch sets the IP address that the client should invoke callback to.
Signed-off-by: NTakuma Umeya <tumeya@redhat.com>
[bfields@redhat.com: Simplify gen_callback arguments, use helper function]
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This avoids the need for the confusing ESRCH mapping.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

These are internal nfsd interfaces.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

According to rfc 3530 BADNAME is for strings that represent paths;
BADOWNER is for user/group names that don't map.

And the too-long name should probably be BADOWNER as well; it's
effectively the same as if we couldn't map it.

Cc: stable@kernel.org
Reported-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Reported-by: NSimon Kirby <sim@hostway.ca>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
  ipv4/route.c: respect prefsrc for local routes
  bridge: stp: ensure mac header is set
  bridge: fix br_multicast_ipv6_rcv for paged skbs
  atl1: fix oops when changing tx/rx ring params
  drivers/atm/atmtcp.c: add missing atm_dev_put
  starfire: Fix dma_addr_t size test for MIPS
  tg3: fix return value check in tg3_read_vpd()
  Broadcom CNIC core network driver: fix mem leak on allocation failures in cnic_alloc_uio_rings()
  ISDN, Gigaset: Fix memory leak in do_disconnect_req()
  CAN: Use inode instead of kernel address for /proc file
  skfp: testing the wrong variable in skfp_driver_init()
  ppp: allow disabling multilink protocol ID compression
  ehea: Avoid changing vlan flags
  ueagle-atm: fix PHY signal initialization race

Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The nfs server only supports read delegations for now, so we don't care
how conflicts are determined.  All we care is that unlocks are
recognized as matching the leases they are meant to remove.  After the
last patch, a comparison of struct files will work for that purpose.  So
we no longer need this callback.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

When we converted to sharing struct filess between nfs4 opens I went too
far and also used the same mechanism for delegations.  But keeping
a reference to the struct file ensures it will outlast the lease, and
allows us to remove the lease with the same file as we added it.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

nfsd controls the lifetime of the lease, not the lock code, so there's
no need for this callback on lease destruction.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Supposes cache_check runs simultaneously with an update on a different
CPU:

	cache_check			task doing update
	^^^^^^^^^^^			^^^^^^^^^^^^^^^^^

	1. test for CACHE_VALID		1'. set entry->data
	   & !CACHE_NEGATIVE

	2. use entry->data		2'. set CACHE_VALID

If the two memory writes performed in step 1' and 2' appear misordered
with respect to the reads in step 1 and 2, then the caller could get
stale data at step 2 even though it saw CACHE_VALID set on the cache
entry.

Add memory barriers to prevent this.
Reviewed-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We attempt to turn a cache entry negative in place.  But that entry may
already have been filled in by some other task since we last checked
whether it was valid, so we could be modifying an already-valid entry.
If nothing else there's a likely leak in such a case when the entry is
eventually put() and contents are not freed because it has
CACHE_NEGATIVE set.

So, take the cache_lock just as sunrpc_cache_update() does.
Reviewed-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We no longer need a few of these special cases.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We no longer need this.

Also, EWOULDBLOCK is generally a synonym for EAGAIN, but that may not be
true on all architectures, so map it as well.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Currently we use -EAGAIN returns to determine when to drop a deferred
request.  On its own, that is error-prone, as it makes us treat -EAGAIN
returns from other functions specially to prevent inadvertent dropping.

So, use a flag on the request instead.

Returning an error on request deferral is still required, to prevent
further processing, but we no longer need worry that an error return on
its own could result in a drop.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Commit d29068c4 "sunrpc: Simplify cache_defer_req and related
functions." asserted that cache_check() could determine success or
failure of cache_defer_req() by checking the CACHE_PENDING bit.

This isn't quite right.

We need to know whether cache_defer_req() created a deferred request,
in which case sending an rpc reply has become the responsibility of the
deferred request, and it is important that we not send our own reply,
resulting in two different replies to the same request.

And the CACHE_PENDING bit doesn't tell us that; we could have
succesfully created a deferred request at the same time as another
thread cleared the CACHE_PENDING bit.

So, partially revert that commit, to ensure that cache_check() returns
-EAGAIN if and only if a deferred request has been created.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
Acked-by: NNeilBrown <neilb@suse.de>

We never want to drop a request if we could return a JUKEBOX/DELAY error
instead; so, convert to nfserr_jukebox and let nfsd_dispatch() convert
that to a dropit error as a last resort if JUKEBOX/DELAY is unavailable
(as in the NFSv2 case).
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

setup_callback_client(), nfsd4_release_cb() and nfsd4_process_cb_update()
do not have users outside the translation unit. Let's declare it as
static.
Signed-off-by: NKirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Signed-off-by: NNeilBrown <neilb@suse.de>
[bfields@redhat.com: moved svcauth_unix_purge outside ifdef's.]
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Once a sunrpc cache entry is VALID, we should be replacing it (and
allowing any concurrent users to destroy it on last put) instead of
trying to update it in place.

Otherwise someone referencing the ip_map we're modifying here could try
to use the m_client just as we're putting the last reference.

The bug should only be seen by users of the legacy nfsd interfaces.

(Thanks to Neil for suggestion to use sunrpc_invalidate.)
Reviewed-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The preferred source address is currently ignored for local routes,
which results in all local connections having a src address that is the
same as the local dst address. Fix this by respecting the preferred source
address when it is provided for local routes.

This bug can be demonstrated as follows:

 # ifconfig dummy0 192.168.0.1
 # ip route show table local | grep local.*dummy0
 local 192.168.0.1 dev dummy0  proto kernel  scope host  src 192.168.0.1
 # ip route change table local local 192.168.0.1 dev dummy0 \
     proto kernel scope host src 127.0.0.1
 # ip route show table local | grep local.*dummy0
 local 192.168.0.1 dev dummy0  proto kernel  scope host  src 127.0.0.1

We now establish a local connection and verify the source IP
address selection:

 # nc -l 192.168.0.1 3128 &
 # nc 192.168.0.1 3128 &
 # netstat -ant | grep 192.168.0.1:3128.*EST
 tcp        0      0 192.168.0.1:3128        192.168.0.1:33228 ESTABLISHED
 tcp        0      0 192.168.0.1:33228       192.168.0.1:3128  ESTABLISHED
Signed-off-by: NJoel Sing <jsing@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ->trim_fs has been removed meanwhile, so remove it from the documentation
as well.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reported-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* master.kernel.org:/home/rmk/linux-2.6-arm:
  ARM: pxa: fix page table corruption on resume
  ARM: it8152: add IT8152_LAST_IRQ definition to fix build error
  ARM: pxa: PXA_ESERIES depends on FB_W100.
  ARM: 6605/1: Add missing include "asm/memory.h"
  ARM: 6540/1: Stop irqsoff trace on return to user
  ARM: 6537/1: update Nomadik, U300 and Ux500 maintainers
  ARM: 6536/1: Add missing SZ_{32,64,128}
  ARM: fix cache-feroceon-l2 after stack based kmap_atomic()
  ARM: fix cache-xsc3l2 after stack based kmap_atomic()
  ARM: get rid of kmap_high_l1_vipt()
  ARM: smp: avoid incrementing mm_users on CPU startup
  ARM: pxa: PXA_ESERIES depends on FB_W100.