- 16 Apr, 2005 12 commits
-
-
David S. Miller authored
I have no idea how a bug like this lasted so long. Anyways, obvious memset()'ing of incorrect pointer. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Stas Sergeev authored
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:
-
akpm@osdl.org authored
) 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:
Andreas Gruenbacher <agruen@suse.de> Signed-off-by:
-
James Bottomley authored
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:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Artem B. Bityuckiy authored
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:
Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
akpm@osdl.org authored
) 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:
Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
akpm@osdl.org authored
) 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:
-
akpm@osdl.org authored
) 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:
-
akpm@osdl.org authored
) 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:
-
Neil Brown authored
..as sync_page_io can be called on the write-out path. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Linus Torvalds authored
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!
-
