linux-toradex.git/include, branch v2.6.27.31

NFS: Fix an O_DIRECT Oops...

2009-08-16T21:27:41+00:00

commit 1ae88b2e446261c038f2c0c3150ffae142b227a2 upstream.

We can't call nfs_readdata_release()/nfs_writedata_release() without
first initialising and referencing args.context. Doing so inside
nfs_direct_read_schedule_segment()/nfs_direct_write_schedule_segment()
causes an Oops.

We should rather be calling nfs_readdata_free()/nfs_writedata_free() in
those cases.

Looking at the O_DIRECT code, the "struct nfs_direct_req" is already
referencing the nfs_open_context for us. Since the readdata and writedata
structures carry a reference to that, we can simplify things by getting rid
of the extra nfs_open_context references, so that we can replace all
instances of nfs_readdata_release()/nfs_writedata_release().

Reported-by: Catalin Marinas 
Signed-off-by: Trond Myklebust 
Tested-by: Catalin Marinas 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

parisc: ensure broadcast tlb purge runs single threaded

2009-08-16T21:26:56+00:00

commit e82a3b75127188f20c7780bec580e148beb29da7 upstream

parisc: ensure broadcast tlb purge runs single threaded
The TLB flushing functions on hppa, which causes PxTLB broadcasts on the system
bus, needs to be protected by irq-safe spinlocks to avoid irq handlers to deadlock
the kernel. The deadlocks only happened during I/O intensive loads and triggered
pretty seldom, which is why this bug went so long unnoticed.

Signed-off-by: Helge Deller 
[edited to use spin_lock_irqsave on UP as well since we'd been locking there
  all this time anyway, --kyle]
Signed-off-by: Kyle McMartin 
Signed-off-by: Greg Kroah-Hartman

x86: fix assembly constraints in native_save_fl()

2009-08-16T21:26:52+00:00

commit f1f029c7bfbf4ee1918b90a431ab823bed812504 upstream.

From Gabe Black in bugzilla 13888:

native_save_fl is implemented as follows:

  11static inline unsigned long native_save_fl(void)
  12{
  13        unsigned long flags;
  14
  15        asm volatile("# __raw_save_flags\n\t"
  16                     "pushf ; pop %0"
  17                     : "=g" (flags)
  18                     : /* no input */
  19                     : "memory");
  20
  21        return flags;
  22}

If gcc chooses to put flags on the stack, for instance because this is
inlined into a larger function with more register pressure, the offset
of the flags variable from the stack pointer will change when the
pushf is performed. gcc doesn't attempt to understand that fact, and
address used for pop will still be the same. It will write to
somewhere near flags on the stack but not actually into it and
overwrite some other value.

I saw this happen in the ide_device_add_all function when running in a
simulator I work on. I'm assuming that some quirk of how the simulated
hardware is set up caused the code path this is on to be executed when
it normally wouldn't.

A simple fix might be to change "=g" to "=r".

Reported-by: Gabe Black 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x25: Fix sleep from timer on socket destroy.

2009-07-30T23:06:13+00:00

[ Upstream commit 14ebaf81e13ce66bff275380b246796fd16cbfa1 ]

If socket destuction gets delayed to a timer, we try to
lock_sock() from that timer which won't work.

Use bh_lock_sock() in that case.

Signed-off-by: David S. Miller 
Tested-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

security: use mmap_min_addr indepedently of security models

2009-07-20T03:44:59+00:00

commit e0a94c2a63f2644826069044649669b5e7ca75d3 upstream.

This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
It also sets a default mmap_min_addr of 4096.

mmapping of addresses below 4096 will only be possible for processes
with CAP_SYS_RAWIO.

Signed-off-by: Christoph Lameter 
Acked-by: Eric Paris 
Looks-ok-by: Linus Torvalds 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

personality: fix PER_CLEAR_ON_SETID (CVE-2009-1895)

2009-07-20T03:44:59+00:00

commit f9fabcb58a6d26d6efde842d1703ac7cfa9427b6 upstream.

We have found that the current PER_CLEAR_ON_SETID mask on Linux doesn't
include neither ADDR_COMPAT_LAYOUT, nor MMAP_PAGE_ZERO.

The current mask is READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE.

We believe it is important to add MMAP_PAGE_ZERO, because by using this
personality it is possible to have the first page mapped inside a
process running as setuid root.  This could be used in those scenarios:

 - Exploiting a NULL pointer dereference issue in a setuid root binary
 - Bypassing the mmap_min_addr restrictions of the Linux kernel: by
   running a setuid binary that would drop privileges before giving us
   control back (for instance by loading a user-supplied library), we
   could get the first page mapped in a process we control.  By further
   using mremap and mprotect on this mapping, we can then completely
   bypass the mmap_min_addr restrictions.

Less importantly, we believe ADDR_COMPAT_LAYOUT should also be added
since on x86 32bits it will in practice disable most of the address
space layout randomization (only the stack will remain randomized).

Signed-off-by: Julien Tinnes 
Signed-off-by: Tavis Ormandy 
Acked-by: Christoph Hellwig 
Acked-by: Kees Cook 
Acked-by: Eugene Teo 
[ Shortened lines and fixed whitespace as per Christophs' suggestion ]
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

IB/mlx4: Add strong ordering to local inval and fast reg work requests

2009-07-02T23:31:47+00:00

commit 2ac6bf4ddc87c3b6b609f8fa82f6ebbffeac12f4 upstream.

The ConnectX Programmer's Reference Manual states that the "SO" bit
must be set when posting Fast Register and Local Invalidate send work
requests.  When this bit is set, the work request will be executed
only after all previous work requests on the send queue have been
executed.  (If the bit is not set, Fast Register and Local Invalidate
WQEs may begin execution too early, which violates the defined
semantics for these operations)

This fixes the issue with NFS/RDMA reported in


Signed-off-by: Jack Morgenstein 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

firmware_map: fix hang with x86/32bit

2009-07-02T23:31:31+00:00

commit 3b0fde0fac19c180317eb0601b3504083f4b9bf5 upstream.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484

Peer reported:
| The bug is introduced from kernel 2.6.27, if E820 table reserve the memory
| above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000
| (reserved)), system will report Int 6 error and hang up. The bug is caused by
| the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit
| variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6
| error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this
| bug.
|======
|static int firmware_map_add_entry(resource_size_t start, resource_size_t end,
|                  const char *type,
|                  struct firmware_map_entry *entry)

and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set.

it turns out we need to pass u64 instead of resource_size_t for that.

[akpm@linux-foundation.org: add comment]
Reported-and-tested-by: Peer Chen 
Signed-off-by: Yinghai Lu 
Cc: Ingo Molnar 
Acked-by: H. Peter Anvin 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ocfs2: fix i_mutex locking in ocfs2_splice_to_file()

2009-05-20T05:20:15+00:00

commit 328eaaba4e41a04c1dc4679d65bea3fee4349d86 upstream.

Rearrange locking of i_mutex on destination and call to
ocfs2_rw_lock() so locks are only held while buffers are copied with
the pipe_to_file() actor, and not while waiting for more data on the
pipe.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

splice: split up __splice_from_pipe()

2009-05-20T05:20:14+00:00

commit b3c2d2ddd63944ef2a1e4a43077b602288107e01 upstream.

Split up __splice_from_pipe() into four helper functions:

  splice_from_pipe_begin()
  splice_from_pipe_next()
  splice_from_pipe_feed()
  splice_from_pipe_end()

splice_from_pipe_next() will wait (if necessary) for more buffers to
be added to the pipe.  splice_from_pipe_feed() will feed the buffers
to the supplied actor and return when there's no more data available
(or if all of the requested data has been copied).

This is necessary so that implementations can do locking around the
non-waiting splice_from_pipe_feed().

This patch should not cause any change in behavior.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman