RDMA needs to post a buffer for each incoming reply.
Hence it needs to keep count of these and needs to be
aware of whether a flushed request has received a reply
or not.

This patch adds the cancelled() callback to the transport modules.
It is called when RFLUSH has been received and that the corresponding
request will never receive a reply.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

In rdma_request():

If an error occurs between posting the recv and the send,
there will be a reply context posted without a pending
request.
Since there is no way to "un-post" it, we remember it and
skip post_recv() for the next request.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

Most importantly:
- do not free the recv context (rpl_context) after a successful post_recv()
- but do free the send context (c) after a failed send.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

rdma_request() should never be in charge of freeing rc.

When an error occurs:
* Either the rc buffer has been recv_post()'ed.
  then kfree()'ing it certainly is a bad idea.
* Or is has not, and in that case req->rc still points to it,
  hence it needs not be freed.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

The current code keeps track of the number of buffers posted in the RQ,
and will prevent it from overflowing. But it does so by simply dropping
post requests (And leaking memory in the process).
When this happens there will actually be too few buffers posted, and
soon the 9P server will complain about 'RNR retry counter exceeded'
errors.

Instead, use a semaphore, and block until the RQ is ready for another
buffer to be posted.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

A well-behaved server would not send twice the reply to a request.
But if it ever happens...
This additional check prevents the kernel from leaking memory
and possibly more nasty consequences in that unlikely event.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

The current value is too low to get good performance.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

p9_tag_alloc() takes care of that.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

The current code assumes that when a request in the request array
does have a tc, it also has a rc.

This is normally true, but not always : when using RDMA, req->rc
will temporarily be set to NULL after the request has been sent.
That is usually OK though, as when the reply arrives, req->rc will be
reassigned to a sane value before the request is recycled.

But there is a catch : if the request is flushed, the reply will never
arrive, and req->rc will be NULL, but not req->tc.

This patch fixes p9_tag_alloc to take this into account.
Signed-off-by: NSimon Derr <simon.derr@bull.net>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

Allow requests for security.* and trusted.* xattr name spaces
to pass through to server.

The new files are 99% cut and paste from fs/9p/xattr_user.c with the
namespaces changed.  It has the intended effect in superficial testing.
I do not know much detail about how these namespaces are used, but passing
them through to the server, which can decide whether to handle them or not,
seems reasonable.

I want to support a use case where an ext4 file system is mounted via 9P,
then re-exported via samba to windows clients in a cluster.  Windows wants
to store xattrs such as security.NTACL.  This works when ext4 directly
backs samba, but not when 9P is inserted.  This use case is documented here:
   http://code.google.com/p/diod/issues/detail?id=95Signed-off-by: NJim Garlick <garlick@llnl.gov>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

If the privport option is specified, the tcp transport binds local
address to a reserved port before connecting to the 9p server.

In some cases when 9P AUTH cannot be implemented, this is better than
nothing.
Signed-off-by: NJim Garlick <garlick@llnl.gov>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

It was missing net and include directories.
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

Additionally change cast from long to unsigned long to follow specificator.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

For zero copy request, error will be encoded in the user space buffer.
So copy the error code correctly using copy_from_user. Here we use the
extra bytes we allocate for zero copy request. If total error details
are more than P9_ZC_HDR_SZ - 7 bytes, we return -EFAULT. The patch also
avoid a memory allocation in the error path.
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

Make the default 9p experience better by defaulting to virtio transport if present.
These days most of the users are using 9p in a virtualized setup
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

If we dont' specify a protocol version default to 9P2000.L. 9P2000.L
have better support for posix semantic and is where all the recent development
is happening.
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>

Pull ARM SoC fix from Olof Johansson:
 "A late-arriving fix for musb on OMAP4, resolving an issue where the
  musb IP won't be clocked and thus not functional.  Small in scope,
  most of the lines changed is a longish comment."

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock

I think we could just move the full vm_iomap_memory() function into
util.h or similar, but I didn't get any reply from anybody actually
using nommu even to this trivial patch, so I'm not going to touch it any
more than required.

Here's the fairly minimal stub to make the nommu case at least
potentially work.  It doesn't seem like anybody cares, though.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull perf fix from Ingo Molnar:
 "This fix adds missing RCU read protection"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  events: Protect access via task_subsys_state_check()

Merge tag 'omap-for-v3.9-rc6/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

From Tony Lindgren:
One MUSB regression fix that I forgot to send earlier. Without
this MUSB no longer works on omap4 based devices.

* tag 'omap-for-v3.9-rc6/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock
Signed-off-by: NOlof Johansson <olof@lixom.net>

Pull media fixes from Mauro Carvalho Chehab:
 "Two driver fixes.

  One avoids reading any file at a system with a cx25821 board
  (fortunately, this is not a common device).  The other one prevents
  reading after a buffer with ISDB-T devices based on mb86a20s."

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] cx25821: do not expose broken video output streams
  [media] mb86a20s: Fix estimate_rate setting

Pull late parisc fixes from Helge Deller:
 "I know it's *very* late in the 3.9 release cycle, but since there
  aren't that many people testing the parisc linux kernel, a few (for
  our port) critical issues just showed up a few days back for the first
  time.

  What's in it?
   - add missing __ucmpdi2 symbol, which is required for btrfs on 32bit
     kernel.
   - change kunmap() macro to static inline function.  This fixes a
     debian/gcc-4.4 build error.
   - add locking when doing PTE updates.  This fixes random userspace
     crashes.
   - disable (optional) -mlong-calls compiler option for modules, else
     modules can't be loaded at runtime.
   - a smart patch by Will Deacon which fixes 64bit put_user() warnings
     on 32bit kernel."

* 'fixes-3.9-late' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: use spin_lock_irqsave/spin_unlock_irqrestore for PTE updates
  parisc: disable -mlong-calls compiler option for kernel modules
  parisc: uaccess: fix compiler warnings caused by __put_user casting
  parisc: Change kunmap macro to static inline function
  parisc: Provide __ucmpdi2 to resolve undefined references in 32 bit builds.

variable_is_present() accesses '__efivars' directly, but when called via
gsmi_init() Michel reports observing the following crash,

  BUG: unable to handle kernel NULL pointer dereference at (null)
  IP: variable_is_present+0x55/0x170
  Call Trace:
    register_efivars+0x106/0x370
    gsmi_init+0x2ad/0x3da
    do_one_initcall+0x3f/0x170

The reason for the crash is that '__efivars' hasn't been initialised nor
has it been registered with register_efivars() by the time the google
EFI SMI driver runs.  The gsmi code uses its own struct efivars, and
therefore, a different variable list.  Fix the above crash by passing
the registered struct efivars to variable_is_present(), so that we
traverse the correct list.
Reported-by: NMichel Lespinasse <walken@google.com>
Tested-by: NMichel Lespinasse <walken@google.com>
Cc: Mike Waychison <mikew@google.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In commit b0de59b5 ("TTY: do not update atime/mtime on read/write")
we removed timestamps from tty inodes to fix a security issue and waited
if something breaks.  Well, 'w', the utility to find out logged users
and their inactivity time broke.  It shows that users are inactive since
the time they logged in.

To revert to the old behaviour while still preventing attackers to
guess the password length, we update the timestamps in one-minute
intervals by this patch.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

dprintk() shouldn't access @ring after it's unmapped.
Signed-off-by: NZhao Hongjiang <zhaohongjiang@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

 * The EFI variable anti-bricking algorithm merged in -rc8 broke booting
   on some Apple machines because they implement EFI spec 1.10, which
   doesn't provide a QueryVariableInfo() runtime function and the logic
   used to check for the existence of that function was insufficient.
   Fix from Josh Boyer.

 * The anti-bricking algorithm also introduced a compiler warning on
   32-bit. Fix from Borislav Petkov.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

User applications running on SMP kernels have long suffered from instability
and random segmentation faults.  This patch improves the situation although
there is more work to be done.

One of the problems is the various routines in pgtable.h that update page table
entries use different locking mechanisms, or no lock at all (set_pte_at).  This
change modifies the routines to all use the same lock pa_dbit_lock.  This lock
is used for dirty bit updates in the interruption code. The patch also purges
the TLB entries associated with the PTE to ensure that inconsistent values are
not used after the page table entry is updated.  The UP and SMP code are now
identical.

The change also includes a minor update to the purge_tlb_entries function in
cache.c to improve its efficiency.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: NHelge Deller <deller@gmx.de>

CONFIG_MLONGCALLS was introduced in commit
ec758f98 to overcome linker issues when linking
huge linux kernels, e.g. with many modules linked in.

But in the kernel module loader there is no support yet for the new relocation
types, which is why modules built with -mlong-calls can't be loaded.
Furthermore, for modules long calls are not really necessary, since we already
use stub sections which resolve long distance calls.

So, let's just disable this compiler option when compiling kernel modules.
Signed-off-by: NHelge Deller <deller@gmx.de>

When targetting 32-bit processors, __put_user emits a pair of stw
instructions for the 8-byte case. If the type of __val is a pointer, the
marshalling code casts it to the wider integer type of u64, resulting
in the following compiler warnings:

  kernel/signal.c: In function 'copy_siginfo_to_user':
  kernel/signal.c:2752:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  kernel/signal.c:2752:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  [...]

This patch fixes the warnings by removing the marshalling code and using
the correct output modifiers in the __put_{user,kernel}_asm64 macros
so that GCC will allocate the right registers without the need to
extract the two words explicitly.

Cc: Helge Deller <deller@gmx.de>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NHelge Deller <deller@gmx.de>

Change kunmap macro to static inline function to fix build error
compiling drivers/base/dma-buf.c.

Without the change, the following error can occur:

   CC      drivers/base/dma-buf.o
drivers/base/dma-buf.c: In function 'dma_buf_kunmap':
drivers/base/dma-buf.c:427:46:
error: macro "kunmap" passed 3 arguments, but takes just 1

I believe parisc is the only arch to implement kunmap using a macro.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: NHelge Deller <deller@gmx.de>

The Debian experimental linux source package (3.8.5-1) build fails
with the following errors:
...
MODPOST 2016 modules
ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__ucmpdi2" [drivers/md/dm-verity.ko] undefined!

The attached patch resolves this problem.  It is based on the s390
implementation of ucmpdi2.c.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Signed-off-by: NHelge Deller <deller@gmx.de>

Pull sparc fix from David Miller:
 "Brown paper bag fix for sparc64"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sparc64: Fix missing put_cpu_var() in tlb_batch_add_one() when not batching.

Pull gpi fix from Linus Walleij:
 "This is a last minute revert for the GPIO tree, as Mike Dunn noticed
  breakage on some older PXA machines due to moving PXA GPIO initcalls
  to the module_init initlevel"

* tag 'gpio-v3.9-lastminute' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  Revert "gpio: pxa: set initcall level to module init"

Reported-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 6c7e660a.

The commit causes breakage on several older PXA machines.
Reported-by: NMike Dunn <mikedunn@newsguy.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We need to check the runtime sys_table for the EFI version the firmware
specifies instead of just checking for a NULL QueryVariableInfo.  Older
implementations of EFI don't have QueryVariableInfo but the runtime is
a smaller structure, so the pointer to it may be pointing off into garbage.

This is apparently the case with several Apple firmwares that support EFI
1.10, and the current check causes them to no longer boot.  Fix based on
a suggestion from Matthew Garrett.
Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Fix this:

arch/x86/boot/compressed/eboot.c: In function ‘setup_efi_vars’:
arch/x86/boot/compressed/eboot.c:269:2: warning: passing argument 1 of ‘efi_call_phys’ makes pointer from integer without a cast [enabled by default]
In file included from arch/x86/boot/compressed/eboot.c:12:0:
/w/kernel/linux/arch/x86/include/asm/efi.h:8:33: note: expected ‘void *’ but argument is of type ‘long unsigned int’

after cc5a080c ("efi: Pass boot services variable info to runtime
code").
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Pull MIPS fix from Ralf Baechle:
 "Revert the change of the definition of PAGE_MASK which was prettier
  but broke a few relativly rare platforms"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  Revert "MIPS: page.h: Provide more readable definition for PAGE_MASK."