Fix the access-above-bottom-of-stack crash.

1. Allows to preserve the valueable optimization

2. Works for NMIs

3.  Doesn't care whether or not there are more of the like instances
   where the stack is left empty.

4. Seems to work for me without the crashes:) 

(akpm: this is still under discussion, although I _think_ it's OK.  You might
want to hold off)

Signed-off-by: Stas Sergeev <stsp@aknet.ru> 
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

)


From: Andreas Gruenbacher <agruen@suse.de>

ext[23]_get_acl will return an error when reading the attribute fails or
out-of-memory occurs.  Catch this case.
Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This was unexported by Arjan because we have no current users.

However, during a conversion from tasklets to workqueues of the parisc led
functions, we ran across a case where this was needed.  In particular, the
open coded equivalent of cancel_rearming_delayed_workqueue was implemented
incorrectly, which is, I think, all the evidence necessary that this is a
useful API.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In the deflate_[compress|uncompress|pcompress] functions we call the
zlib_[in|de]flateReset function at the beginning.  This is OK.  But when we
unload the deflate module we don't call zlib_[in|de]flateEnd to free all
the zlib internal data.  It looks like a bug for me.  Please, consider the
attached patch.
Signed-off-by: NArtem B. Bityuckiy <dedekind@infradead.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

)


From: Russell King <rmk+lkml@arm.linux.org.uk>

Oddly, max_low_pfn/max_pfn end up being the number of pages in the system,
rather than the maximum PFN on ARM.  This doesn't seem to cause any problems,
so just add a note about it.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

)


From: Russell King <rmk+lkml@arm.linux.org.uk>

The ARM dma_supported() is rather basic, and I don't think it takes into
account everything that it should do (eg, whether the mask agrees with what
we'd return for GFP_DMA allocations).  Note this.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

)


From: Russell King <rmk+lkml@arm.linux.org.uk>

For some reason, this help text was missed when the file was last audited
by the documentation referencing folk.  Fix this incorrect documentation
reference.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

)


From: Russell King <rmk+lkml@arm.linux.org.uk>

ARM wasn't raising a SIGBUS with a siginfo structure.  Fix
__do_user_fault() to allow us to use it for SIGBUS conditions, and arrange
for the sigbus path to use this.

We need to prevent the siginfo code being called if we do not have a user
space context to call it, so consolidate the "user_mode()" tests.

Thanks to Ian Campbell who spotted this oversight.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

..as sync_page_io can be called on the write-out path.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!