user/sven/linux.git, branch v2.6.16.22

Linux 2.6.16.22

2006-06-22T19:16:21Z

[PATCH] NTFS: Critical bug fix (affects MIPS and possibly others)

2006-06-22T19:16:12Z

It fixes a crash in NTFS on architectures where flush_dcache_page() is a real function. I never noticed this as all my testing is done on i386 where flush_dcache_page() is NULL. http://bugzilla.kernel.org/show_bug.cgi?id=6700 Many thanks to Pauline Ng for the detailed bug report and analysis! Signed-off-by: Anton Altaparmakov Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] powernow-k8 crash workaround

2006-06-22T19:16:12Z

Work around the oops reported in http://bugzilla.kernel.org/show_bug.cgi?id=6478. Thanks to Ralf Hildebrandt for testing and reporting. Acked-by: Dave Jones Cc: "Brown, Len" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] I2O: Bugfixes to get I2O working again

2006-06-22T19:16:12Z

- Fixed locking of struct i2o_exec_wait in Executive-OSM - Removed LCT Notify in i2o_exec_probe() which caused freeing memory and accessing freed memory during first enumeration of I2O devices - Added missing locking in i2o_exec_lct_notify() - removed put_device() of I2O controller in i2o_iop_remove() which caused the controller structure get freed to early - Fixed size of mempool in i2o_iop_alloc() - Fixed access to freed memory in i2o_msg_get() See http://bugzilla.kernel.org/show_bug.cgi?id=6561 Signed-off-by: Markus Lidel Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] scsi_lib.c: properly count the number of pages in scsi_req_map_sg()

2006-06-22T19:16:12Z

The calculation of nr_pages in scsi_req_map_sg() doesn't account for the fact that the first page could have an offset that pushes the end of the buffer onto a new page. Signed-off-by: Bryan Holty Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] JFS: Fix multiple errors in metapage_releasepage

2006-06-22T19:16:12Z

It looks like metapage_releasepage was making in invalid assumption that the releasepage method would not be called on a dirty page. Instead of issuing a warning and releasing the metapage, it should return 0, indicating that the private data for the page cannot be released. I also realized that metapage_releasepage had the return code all wrong. If it is successful in releasing the private data, it should return 1, otherwise it needs to return 0. Lastly, there is no need to call wait_on_page_writeback, since try_to_release_page will not call us with a page in writback state. Signed-off-by: Dave Kleikamp Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] fs/namei.c: Call to file_permission() under a spinlock in do_lookup_path()

2006-06-22T19:16:12Z

We're presently running lock_kernel() under fs_lock via nfs's ->permission handler. That's a ranking bug and sometimes a sleep-in-spinlock bug. This problem was introduced in the openat() patchset. We should not need to hold the current->fs->lock for a codepath that doesn't use current->fs. [vsu@altlinux.ru: fix error path] Signed-off-by: Trond Myklebust Cc: Al Viro Signed-off-by: Sergey Vlasov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] tmpfs: time granularity fix for [acm]time going backwards

2006-06-22T19:16:12Z

I noticed a strange behavior in a tmpfs file system the other day, while building packages - occasionally, and seemingly at random, make decided to rebuild a target. However, only on tmpfs. A file would be created, and if checked, it had a sub-second timestamp. However, after an utimes related call where sub-seconds should be set, they were zeroed instead. In the case that a file was created, and utimes(...,NULL) was used on it in the same second, the timestamp on the file moved backwards. After some digging, I found that this was being caused by tmpfs not having a time granularity set, thus inheriting the default 1 second granularity. Hugh adds: yes, we missed tmpfs when the s_time_gran mods went into 2.6.11. Unfortunately, the granularity of CURRENT_TIME, often used in filesystems, does not match the default granularity set by alloc_super. A few more such discrepancies have been found, but this is the most important to fix now. Signed-off-by: Robin H. Johnson Acked-by: Andi Kleen Signed-off-by: Hugh Dickins Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] Missed error checking for intent's filp in open_namei().

2006-06-22T19:16:12Z

It seems there is error check missing in open_namei for errors returned through intent.open.file (from lookup_instantiate_filp). If there is plain open performed, then such a check done inside __path_lookup_intent_open called from path_lookup_open(), but when the open is performed with O_CREAT flag set, then __path_lookup_intent_open is only called with LOOKUP_PARENT set where no file opening can occur yet. Later on lookup_hash is called where exact opening might take place and intent.open.file may be filled. If it is filled with error value of some sort, then we get kernel attempting to dereference this error value as address (and corresponding oops) in nameidata_to_filp() called from filp_open(). While this is relatively simple to workaround in ->lookup() method by just checking lookup_instantiate_filp() return value and returning error as needed, this is not so easy in ->d_revalidate(), where we can only return "yes, dentry is valid" or "no, dentry is invalid, perform full lookup again", and just returning 0 on error would cause extra lookup (with potential extra costly RPCs). So in short, I believe that there should be no difference in error handling for opening a file and creating a file in open_namei() and propose this simple patch as a solution. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] SPARC64: Fix missing fold at end of checksums.

2006-06-22T19:16:11Z

Both csum_partial() and the csum_partial_copy*() family of routines forget to do a final fold on the computed checksum value on sparc64. So do the standard Sparc "add + set condition codes, add carry" sequence, then make sure the high 32-bits of the return value are clear. Based upon some excellent detective work and debugging done by Richard Braun and Samuel Thibault. Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman