It's not enough to take a reference on the delegation object itself; we
need to ensure that the rpc_client won't go away just as we're about to
make an rpc call.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

If a callback still holds a reference on the client, then it may be
about to perform an rpc call, so it isn't safe to call rpc_shutdown().
(Though rpc_shutdown() does wait for any outstanding rpc's, it can't
know if a new rpc is about to be issued with that client.)

So, wait to shutdown the rpc_client until the reference count on the
client has gone to zero.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Currently there's a race that can cause an oops in generic_setlease.

(In detail: nfsd, when it removes a lease, does so by calling
vfs_setlease() with F_UNLCK and a pointer to the fl_flock field, which
in turn points to nfsd's existing lease; but the first thing the
setlease code does is call time_out_leases().  If the lease happens to
already be beyond the lease break time, that will free the lease and (in
nfsd's release_private callback) set fl_flock to NULL, leading to a NULL
deference soon after in vfs_setlease().)

There are probably other things to fix here too, but it seems inherently
racy to allow either locks.c or nfsd to time out this lease.  Instead
just set the fl_break_time to 0 (preventing locks.c from ever timing out
this lock) and leave it up to nfsd's laundromat thread to deal with it.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

This patch adds the address of the client that caused an error in
sunrpc/svc.c so that you get errors that look like:

svc: 192.168.66.28, port=709: unknown version (3 for prog 100003, nfsd)

I've seen machines which get bunches of unknown version or similar
errors from time to time, and while the recent patch to add the service
helps to find which service has the wrong version it doesn't help find
the potentially bad client.

The patch is against a checkout of Linus's git tree made on 2007-08-24.

One observation is that the svc_print_addr function prints to a buffer
which in this case makes life a little more complex; it just feels as if
there must be lots of places that print a connection address - is there
a better function to use anywhere?

I think actually there are a few places with semi duplicated code; e.g.
one_sock_name switches on the address family but only currently has
IPV4; I wonder how many other places are similar.
Signed-off-by: NDave Gilbert <linux@treblig.org>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

Modify the NFS server code to support 64 bit ino's, as
appropriate for the system and the NFS protocol version.

The gist of the changes is to query the underlying file system
for attributes and not just to use the cached attributes in the
inode.  For this specific purpose, the inode only contains an
ino field which unsigned long, which is large enough on 64 bit
platforms, but is not large enough on 32 bit platforms.

I haven't been able to find any reason why ->getattr can't be called
while i_mutex.  The specification indicates that i_mutex is not
required to be held in order to invoke ->getattr, but it doesn't say
that i_mutex can't be held while invoking ->getattr.

I also haven't come to any conclusions regarding the value of
lease_get_mtime() and whether it should or should not be invoked
by fill_post_wcc() too.  I chose not to change this because I
thought that it was safer to leave well enough alone.  If we
decide to make a change, it can be done separately.
Signed-off-by: NPeter Staubach <staubach@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

We've let svcauth_gss_accept() get much too long and hairy.  The
RPC_GSS_PROC_INIT and RPC_GSS_PROC_CONTINUE_INIT cases share very little
with the other cases, so it's very natural to split them off into a
separate function.

This will also nicely isolate the piece of code we need to parametrize
to authenticating gss-protected NFSv4 callbacks on behalf of the NFS
client.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

Each branch of this if-then-else has a bunch of duplicated code that we
could just put at the end.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

fs/nfsd/nfsctl.c: In function 'write_filehandle':
fs/nfsd/nfsctl.c:301: warning: 'maxsize' may be used uninitialized in this function
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

It doesn't make sense to make the callback with credentials that the
client made the setclientid with.  Instead the spec requires that the
callback occur with the credentials the client authenticated *to*.
It probably doesn't matter what we use for auth_unix, and some more
infrastructure will be needed for auth_gss, so let's just remove the
cred lookup for now.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

We have some slabs that the nfs4 server uses to store state objects.
We're currently creating and destroying those slabs whenever the server
is brought up or down.  That seems excessive; may as well just do that
in module initialization and exit.

Also add some minor header cleanup.  (Thanks to Andrew Morton for that
and a compile fix.)
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

We want to allow gss on the callback channel, so people using krb5 can
still get the benefits of delegations.

But looking up the rpc credential can take some time in that case.  And
we shouldn't delay the response to setclientid_confirm while we wait.

It may be inefficient, but for now the simplest solution is just to
spawn a new thread as necessary for the purpose.

(Thanks to Adrian Bunk for catching a missing static here.)
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Cc: Adrian Bunk <bunk@kernel.org>

Note that qword_get() returns length or -1, not an -ERROR.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

To quote a recent mail from Andrew Morton:

	Look: if there's a way in which an unprivileged user can trigger
	a printk we fix it, end of story.

OK.  I assume that goes double for printk()s that might be triggered by
random hosts on the internet.  So, disable some printk()s that look like
they could be triggered by malfunctioning or malicious clients.  For
now, just downgrade them to dprintk()s.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

Benny Halevy suggested renaming cmp_* to same_* to make the meaning of
the return value clearer.

Fix some nearby style deviations while we're at it, including a small
swath of creative indentation in nfs4_preprocess_seqid_op().
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

I moved this check into map_new_errors, but forgot to delete the
original.  Oops.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

This macro is unused.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

The nfserr_dropit happens routinely on upcalls (so a kmalloc failure is
almost never the actual cause), but I occasionally get a complant from
some tester that's worried because they ran across this message after
turning on debugging to research some unrelated problem.
Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NNeil Brown <neilb@suse.de>

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] Au1000: set the PCI controller IO base
  [MIPS] Alchemy: Fix USB initialization.
  [MIPS] IP32: Fix fatal typo in address computation.

The recent fix for a circular lock dependency unfortunately introduced a
potential memory leak in the event where the call to nlmsvc_lookup_host
fails for some reason.

Thanks to Roel Kluin for spotting this.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The recent mv_fill_sg() rewrite, to fix a data corruption problem
related to IOMMU virtual merging, forgot to account for the
potentially-increased size of the scatter/gather table after its run.

Additionally, the DMA boundary is reduced from 0xffffffff to 0xffff
to more closely match the needs of mv_fill_sg().
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The PCI controller IO base was not set in the au1000 pci code.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn Crispin <blogic@openwrt.org>
Signed-off-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch fixes a wrong ifdef in the board setup code, leading to the GPIO
pin not being pulled high, and thus the USB switch not being powered at all.

This finishes the rename of CONFIG_USB_OHCI to CONFIG_USB_OHCI_HCD, which
started in 2005 (before 2.6.12-rc2), then probably because things were
working anyway for most people got forgotten.

[Ralf: Paolo's original patch didn't fix the module case, Florian's patch
only fixed MTX1 etc. so this is a combined patch plus some cleanups.]

Cc: Giuseppe Patanè <giuseppe.patane@tvblob.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn Crispin <blogic@openwrt.org>
Signed-off-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NGiuseppe Sacco <eppesuig@debian.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

When building a custom keymap, after setting GENERATE_KEYMAP := 1 in
drivers/char/Makefile, the kernel build fails like this:

    CC      drivers/char/vt.o
  make[2]: *** No rule to make target `drivers/char/%.map', needed by `drivers/char/defkeymap.c'.  Stop.
  make[1]: *** [drivers/char] Error 2
  make: *** [drivers] Error 2

This was caused by commit af8b1287, which
deleted a necessary colon from the Makefile rule that generates the keymap,
since that rule contains both a target and a target-pattern.  The following
patch puts the colon back:
Signed-off-by: NMaarten Bressers <mbres@gentoo.org>
Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix against access random data bytes outside the dev->chanmap array.
Thanks to Oliver Neukum for pointing me to this issue.
Signed-off-by: NKarsten Keil <kkeil@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [IPv6]: Fix ICMPv6 redirect handling with target multicast address
  [PKT_SCHED] cls_u32: error code isn't been propogated properly
  [ROSE]: Fix rose.ko oops on unload
  [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed

When IOCB_FLAG_RESFD flag is set and iocb->aio_resfd is incorrect,
statement 'goto out_put_req' is executed. At label 'out_put_req',
aio_put_req(..) is called, which requires 'req->ki_filp' set.

Signed-off-by: Yan Zheng<yanzheng@21cn.com>
Cc: Zach Brown <zach.brown@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

find_lock_page increases page's usage count, we should decrease it
before return VM_FAULT_SIGBUS

Signed-off-by: Yan Zheng<yanzheng@21cn.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The test for VM_CAN_NONLINEAR always fails

Signed-off-by: Yan Zheng<yanzheng@21cn.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

All the current page_mkwrite() implementations also set the page dirty. Which
results in the set_page_dirty_balance() call to _not_ call balance, because the
page is already found dirty.

This allows us to dirty a _lot_ of pages without ever hitting
balance_dirty_pages().  Not good (tm).

Force a balance call if ->page_mkwrite() was successful.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When the ICMPv6 Target address is multicast, Linux processes the 
redirect instead of dropping it.  The problem is in this code in 
ndisc_redirect_rcv():

         if (ipv6_addr_equal(dest, target)) {
                 on_link = 1;
         } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                 ND_PRINTK2(KERN_WARNING
                            "ICMPv6 Redirect: target address is not 
link-local.\n");
                 return;
         }

This second check will succeed if the Target address is, for example, 
FF02::1 because it has link-local scope.  Instead, it should be checking 
if it's a unicast link-local address, as stated in RFC 2461/4861 Section 
8.1:

       - The ICMP Target Address is either a link-local address (when
         redirected to a router) or the same as the ICMP Destination
         Address (when redirected to the on-link destination).

I know this doesn't explicitly say unicast link-local address, but it's 
implied.

This bug is preventing Linux kernels from achieving IPv6 Logo Phase II 
certification because of a recent error that was found in the TAHI test 
suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the 
multicast address in the Destination field instead of Target field, so 
we were passing the test.  This won't be the case anymore.

The patch below fixes this problem, and also fixes ndisc_send_redirect() 
to not send an invalid redirect with a multicast address in the Target 
field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux 
passes all 245 tests now.
Signed-off-by: NBrian Haley <brian.haley@hp.com>
Acked-by: NDavid L Stevens <dlstevens@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit a3d38402 aka
"[AX.25]: Fix unchecked rose_add_loopback_neigh uses"
transformed rose_loopback_neigh var into statically allocated one.
However, on unload it will be kfree's which can't work.

Steps to reproduce:

	modprobe rose
	rmmod rose

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008
 printing eip:
c014c664
*pde = 00000000
Oops: 0000 [#1]
PREEMPT DEBUG_PAGEALLOC
Modules linked in: rose ax25 fan ufs loop usbhid rtc snd_intel8x0 snd_ac97_codec ehci_hcd ac97_bus uhci_hcd thermal usbcore button processor evdev sr_mod cdrom
CPU:    0
EIP:    0060:[<c014c664>]    Not tainted VLI
EFLAGS: 00210086   (2.6.23-rc9 #3)
EIP is at kfree+0x48/0xa1
eax: 00000556   ebx: c1734aa0   ecx: f6a5e000   edx: f7082000
esi: 00000000   edi: f9a55d20   ebp: 00200287   esp: f6a5ef28
ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068
Process rmmod (pid: 1823, ti=f6a5e000 task=f7082000 task.ti=f6a5e000)
Stack: f9a55d20 f9a5200c 00000000 00000000 00000000 f6a5e000 f9a5200c f9a55a00 
       00000000 bf818cf0 f9a51f3f f9a55a00 00000000 c0132c60 65736f72 00000000 
       f69f9630 f69f9528 c014244a f6a4e900 00200246 f7082000 c01025e6 00000000 
Call Trace:
 [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose]
 [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose]
 [<f9a51f3f>] rose_exit+0x4c/0xd5 [rose]
 [<c0132c60>] sys_delete_module+0x15e/0x186
 [<c014244a>] remove_vma+0x40/0x45
 [<c01025e6>] sysenter_past_esp+0x8f/0x99
 [<c012bacf>] trace_hardirqs_on+0x118/0x13b
 [<c01025b6>] sysenter_past_esp+0x5f/0x99
 =======================
Code: 05 03 1d 80 db 5b c0 8b 03 25 00 40 02 00 3d 00 40 02 00 75 03 8b 5b 0c 8b 73 10 8b 44 24 18 89 44 24 04 9c 5d fa e8 77 df fd ff <8b> 56 08 89 f8 e8 84 f4 fd ff e8 bd 32 06 00 3b 5c 86 60 75 0f 
EIP: [<c014c664>] kfree+0x48/0xa1 SS:ESP 0068:f6a5ef28
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When only GSO skb was partially ACKed, no hints are reset,
therefore fastpath_cnt_hint must be tweaked too or else it can
corrupt fackets_out. The corruption to occur, one must have
non-trivial ACK/SACK sequence, so this bug is not very often
that harmful. There's a fackets_out state reset in TCP because
fackets_out is known to be inaccurate and that fixes the issue
eventually anyway.

In case there was also at least one skb that got fully ACKed,
the fastpath_skb_hint is set to NULL which causes a recount for
fastpath_cnt_hint (the old value won't be accessed anymore),
thus it can safely be decremented without additional checking.

Reported by Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We should only reparent to a class former class devices that
form the base of class hierarchy. Nested devices should still
grow from their real parents.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Tested-by: NAnssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: point to migration document

Add the manufacturer and card id of teltonica pcmcia modems to serial_cs.c
Signed-off-by: NAttila Kinali <attila@kinali.ch>
Acked-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Document sequence of keypresses that actually works. Yes, this changed
year-or-so ago.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>