fuse: add FUSE_AUTO_INVAL_DATA init flag

FUSE_AUTO_INVAL_DATA is provided to enable updated/auto cache
invalidation logic.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
fuse: invalidate inode mapping if mtime changes

We currently invalidate the inode address space mapping
if the file size changes unexpectedly. In the case of a
fuse network filesystem, a portion of a file could be
overwritten remotely without changing the file size.
Compare the old mtime as well to detect this condition
and invalidate the mapping if the file has been updated.

The original logic (to ignore changes in mtime) is
preserved unless the client specifies FUSE_AUTO_INVAL_DATA
on init.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
fuse: update attributes on aio_read

A fuse-based network filesystem might allow for the inode
and/or file data to change unexpectedly. A local client
that opens and repeatedly reads a file might never pick
up on such changes and indefinitely return stale data.

Always invoke fuse_update_attributes() in the read path
to cause an attr revalidation when the attributes expire.
This leads to a page cache invalidation if necessary and
ensures fuse issues new read requests to the fuse client.

The original logic (reval only on reads beyond EOF) is
preserved unless the client specifies FUSE_AUTO_INVAL_DATA
on init.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
fuse: add missing INIT flags

Add missing flags that userspace derived from the protocol version number.  This
makes the protocol more flexible.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
fuse: add missing INIT flag descriptions

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.

When we release pages back during bootup:

Freeing  9d-100 pfn range: 99 pages freed
Freeing  9cf36-9d0d2 pfn range: 412 pages freed
Freeing  9f6bd-9f6bf pfn range: 2 pages freed
Freeing  9f714-9f7bf pfn range: 171 pages freed
Freeing  9f7e0-9f7ff pfn range: 31 pages freed
Freeing  9f800-100000 pfn range: 395264 pages freed
Released 395979 pages of unused memory

We then try to populate those pages back. In the P2M tree however
the space for those leafs must be reserved - as such we use extend_brk.
We reserve 8MB of _brk space, which means we can fit over
1048576 PFNs - which is more than we should ever need.

Without this, on certain compilation of the kernel we would hit:

(XEN) domain_crash_sync called from entry.S
(XEN) CPU:    0
(XEN) RIP:    e033:[<ffffffff818aad3b>]
(XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
(XEN) rax: ffffffff81a7c000   rbx: 000000000000003d   rcx: 0000000000001000
(XEN) rdx: ffffffff81a7b000   rsi: 0000000000001000   rdi: 0000000000001000
(XEN) rbp: ffffffff81801cd8   rsp: ffffffff81801c98   r8:  0000000000100000
(XEN) r9:  ffffffff81a7a000   r10: 0000000000000001   r11: 0000000000000003
(XEN) r12: 0000000000000004   r13: 0000000000000004   r14: 000000000000003d
(XEN) r15: 00000000000001e8   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) cr3: 0000000125803000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81801c98:

.. which is extend_brk hitting a BUG_ON.

Interestingly enough, most of the time we are not going to hit this
b/c the _brk space is quite large (v3.5):
 ffffffff81a25000 B __brk_base
 ffffffff81e43000 B __brk_limit
= ~4MB.

vs earlier kernels (with this back-ported), the space is smaller:
 ffffffff81a25000 B __brk_base
 ffffffff81a7b000 B __brk_limit
= 344 kBytes.

where we would certainly hit this and hit extend_brk.

Note that git commit c3d93f880197953f86ab90d9da4744e926b38e33
(xen: populate correct number of pages when across mem boundary (v2))
exposed this bug).

[v1: Made it 8MB of _brk space instead of 4MB per Jan's suggestion]

CC: stable@vger.kernel.org #only for 3.5
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
fuse: verify all ioctl retry iov elements

Commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that
the total iovec from the client doesn't overflow iov_length() but it
only checked the first element.  The iovec could still overflow by
starting with a small element.  The obvious fix is to check all the
elements.

The overflow case doesn't look dangerous to the kernel as the copy is
limited by the length after the overflow.  This fix restores the
intention of returning an error instead of successfully copying less
than the iovec represented.

I found this by code inspection.  I built it but don't have a test case.
I'm cc:ing stable because the initial commit did as well.

Signed-off-by: Zach Brown <zab@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
CC: <stable@vger.kernel.org>         [2.6.37+]
vfio: Include vfio.h in installed headers

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
sh: dma: fix request_irq usage

When calling request_irq with IRQF_SHARED, the dev cookie must be set
(i.e. non-NULL), otherwise the code rejects it immediately with -EINVAL.
So restore the logic here where we'd pass a pointer to the name as a
dummy unique val.

Otherwise, booting up on my LANDISK system would fail with:
	DMAC Address Error0 request_irq fail

This was introduced in commit 7f47c7189b3e8f19a589f77a3ad169d7b691b582.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sh: sh7269: Fix LCD pinmux

There are two ports that can output the LCD data, therefore
they have to use separate pimux identifiers so we can select
the one we want to use.

Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sh: intc: Handle domain association for sparseirq pre-allocated vectors.

Presently it's assumed that the irqdomain code handles the irq_desc
allocation for us, but this isn't necessarily the case when we've
pre-allocated IRQs via sparseirq. Previously we had a -EEXIST check in
the code that attempted to trap these cases and simply update them
in-place, but this behaviour was inadvertently lost in the transition to
irqdomains.

This simply restores the previous behaviour, first attempting to let the
irqdomain core fetch the allocation for us, and falling back to an
in-place domain association in the extant IRQ case. Fixes up regressions
on platforms that pre-allocate legacy IRQs (specifically ARM-based
SH-Mobile platforms, as SH stopped pre-allocating vectors some time ago).

Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Merge branches 'sh/urgent' and 'sh/gpiolib' into sh-latest
MAINTAINERS: update address for Dan Williams

Moved to djbw@fb.com

Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Dan Williams <djbw@fb.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'sh-for-linus' of git://github.com/pmundt/linux-sh

Pull SuperH fixes from Paul Mundt.

* tag 'sh-for-linus' of git://github.com/pmundt/linux-sh:
  sh: intc: Handle domain association for sparseirq pre-allocated vectors.
  sh: sh7269: Fix LCD pinmux
  sh: dma: fix request_irq usage
Merge tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Pull Xen fix from Konrad Rzeszutek Wilk:
 "Way back in v3.5 we added a mechanism to populate back pages that were
  released (they overlapped with MMIO regions), but neglected to reserve
  the proper amount of virtual space for extend_brk to work properly.

  Coincidentally some other commit aligned the _brk space to larger area
  so I didn't trigger this until it was run on a machine with more than
  2GB of MMIO space."

 * On machines with large MMIO/PCI E820 spaces we fail to boot b/c
   we failed to pre-allocate large enough virtual space for extend_brk.

* tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse

Pull fuse updates from Miklos Szeredi.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
  fuse: verify all ioctl retry iov elements
  fuse: add missing INIT flag descriptions
  fuse: add missing INIT flags
  fuse: update attributes on aio_read
  fuse: invalidate inode mapping if mtime changes
  fuse: add FUSE_AUTO_INVAL_DATA init flag
Merge tag 'vfio-for-v3.6-rc1' of git://github.com/awilliam/linux-vfio

Pull VFIO fix from Alex Williamson:
 "Just a trivial patch to include vfio.h in the installed headers so we
  can complete userspace integration into QEMU."

* tag 'vfio-for-v3.6-rc1' of git://github.com/awilliam/linux-vfio:
  vfio: Include vfio.h in installed headers
autofs4 - fix get_next_positive_subdir()

Following a report of a crash during an automount expire I found that
the locking in fs/autofs4/expire.c:get_next_positive_subdir() was wrong.
Not only is the locking wrong but the function is more complex than it
needs to be.

The function is meant to calculate (and dget) the next entry in the list
of directories contained in the root of an autofs mount point (an autofs
indirect mount to be precise). The main problem was that the d_lock of
the owner of the list was not being taken when walking the list, which
lead to list corruption under load. The only other lock that needs to
be taken is against the next dentry candidate so it can be checked for
usability.

Signed-off-by: Ian Kent <raven@themaw.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linux 3.6-rc2