* [patch 00/13] 2.6.23-stable review, core kernel changes
@ 2007-11-15 6:05 ` Greg KH
2007-11-15 6:09 ` [patch 01/13] lockdep: fix mismatched lockdep_depth/curr_chain_hash Greg KH
` (12 more replies)
0 siblings, 13 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan
This is the start of the stable review cycle for the 2.6.23.X release.
There are 13 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let us know. If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email stable@kernel.org
to add your name to the list. If you want to be off the reviewer list,
also email us.
Responses should be made by Friday 00:00:00 UTC. Anything received
after that time might be too late.
This set of patches focuses on only the core kernel. Other sets of
patches will follow if you are interested in those instead.
The diffstat of this review series is included below.
thanks,
greg k-h
---------------
Documentation/ja_JP/HOWTO | 84 ++++++++++++++++++++++++----------------------
block/ll_rw_blk.c | 8 +---
fs/locks.c | 11 ++++++
fs/proc/array.c | 6 ++-
fs/splice.c | 2 -
include/linux/blkdev.h | 2 -
include/linux/sched.h | 1
kernel/fork.c | 2 +
kernel/futex_compat.c | 27 ++++++++++----
kernel/lockdep.c | 10 ++---
kernel/params.c | 8 +++-
kernel/softlockup.c | 7 ++-
mm/filemap.c | 13 +------
mm/page-writeback.c | 4 +-
mm/shmem.c | 15 ++++++++
mm/slub.c | 22 ------------
16 files changed, 125 insertions(+), 97 deletions(-)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 01/13] lockdep: fix mismatched lockdep_depth/curr_chain_hash
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 02/13] locks: fix possible infinite loop in posix deadlock detection Greg KH
` (11 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Gregory Haskins, Peter Zijlstra, Ingo Molnar
[-- Attachment #1: lockdep-fix-mismatched-lockdep_depth-curr_chain_hash.patch --]
[-- Type: text/plain, Size: 2177 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Gregory Haskins <ghaskins@novell.com>
patch 3aa416b07f0adf01c090baab26fb70c35ec17623 in mainline.
It is possible for the current->curr_chain_key to become inconsistent
with the current index if the chain fails to validate. The end result
is that future lock_acquire() operations may inadvertently fail to find
a hit in the cache resulting in a new node being added to the graph for
every acquire.
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/lockdep.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -1521,7 +1521,7 @@ cache_hit:
}
static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
- struct held_lock *hlock, int chain_head)
+ struct held_lock *hlock, int chain_head, u64 chain_key)
{
/*
* Trylock needs to maintain the stack of held locks, but it
@@ -1534,7 +1534,7 @@ static int validate_chain(struct task_st
* graph_lock for us)
*/
if (!hlock->trylock && (hlock->check == 2) &&
- lookup_chain_cache(curr->curr_chain_key, hlock->class)) {
+ lookup_chain_cache(chain_key, hlock->class)) {
/*
* Check whether last held lock:
*
@@ -1576,7 +1576,7 @@ static int validate_chain(struct task_st
#else
static inline int validate_chain(struct task_struct *curr,
struct lockdep_map *lock, struct held_lock *hlock,
- int chain_head)
+ int chain_head, u64 chain_key)
{
return 1;
}
@@ -2450,11 +2450,11 @@ static int __lock_acquire(struct lockdep
chain_head = 1;
}
chain_key = iterate_chain_key(chain_key, id);
- curr->curr_chain_key = chain_key;
- if (!validate_chain(curr, lock, hlock, chain_head))
+ if (!validate_chain(curr, lock, hlock, chain_head, chain_key))
return 0;
+ curr->curr_chain_key = chain_key;
curr->lockdep_depth++;
check_chain_key(curr);
#ifdef CONFIG_DEBUG_LOCKDEP
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 02/13] locks: fix possible infinite loop in posix deadlock detection
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
2007-11-15 6:09 ` [patch 01/13] lockdep: fix mismatched lockdep_depth/curr_chain_hash Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 03/13] Remove broken ptrace() special-case code from file mapping Greg KH
` (10 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable, Linus Torvalds
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, akpm, alan, George G. Davis,
linux-fsdevel, J. Bruce Fields, Alan Cox
[-- Attachment #1: locks-fix-possible-infinite-loop-in-posix-deadlock-detection.patch --]
[-- Type: text/plain, Size: 2089 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: J. Bruce Fields <bfields@citi.umich.edu>
patch 97855b49b6bac0bd25f16b017883634d13591d00 in mainline.
It's currently possible to send posix_locks_deadlock() into an infinite
loop (under the BKL).
For now, fix this just by bailing out after a few iterations. We may
want to fix this in a way that better clarifies the semantics of
deadlock detection. But that will take more time, and this minimal fix
is probably adequate for any realistic scenario, and is simple enough to
be appropriate for applying to stable kernels now.
Thanks to George Davis for reporting the problem.
Cc: "George G. Davis" <gdavis@mvista.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/locks.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -694,11 +694,20 @@ EXPORT_SYMBOL(posix_test_lock);
* Note: the above assumption may not be true when handling lock requests
* from a broken NFS client. But broken NFS clients have a lot more to
* worry about than proper deadlock detection anyway... --okir
+ *
+ * However, the failure of this assumption (also possible in the case of
+ * multiple tasks sharing the same open file table) also means there's no
+ * guarantee that the loop below will terminate. As a hack, we give up
+ * after a few iterations.
*/
+
+#define MAX_DEADLK_ITERATIONS 10
+
static int posix_locks_deadlock(struct file_lock *caller_fl,
struct file_lock *block_fl)
{
struct list_head *tmp;
+ int i = 0;
next_task:
if (posix_same_owner(caller_fl, block_fl))
@@ -706,6 +715,8 @@ next_task:
list_for_each(tmp, &blocked_list) {
struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link);
if (posix_same_owner(fl, block_fl)) {
+ if (i++ > MAX_DEADLK_ITERATIONS)
+ return 0;
fl = fl->fl_next;
block_fl = fl;
goto next_task;
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 03/13] Remove broken ptrace() special-case code from file mapping
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
2007-11-15 6:09 ` [patch 01/13] lockdep: fix mismatched lockdep_depth/curr_chain_hash Greg KH
2007-11-15 6:09 ` [patch 02/13] locks: fix possible infinite loop in posix deadlock detection Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 04/13] param_sysfs_builtin memchr argument fix Greg KH
` (9 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Duane Griffin, Nick Piggin
[-- Attachment #1: remove-broken-ptrace-special-case-code-from-file-mapping.patch --]
[-- Type: text/plain, Size: 2128 bytes --]
stable review patch. If anyone has any objections, please let us know.
------------------
The kernel has for random historical reasons allowed ptrace() accesses
to access (and insert) pages into the page cache above the size of the
file.
However, Nick broke that by mistake when doing the new fault handling in
commit 54cb8821de07f2ffcd28c380ce9b93d5784b40d7 ("mm: merge populate and
nopage into fault (fixes nonlinear)". The breakage caused a hang with
gdb when trying to access the invalid page.
The ptrace "feature" really isn't worth resurrecting, since it really is
wrong both from a portability _and_ from an internal page cache validity
standpoint. So this removes those old broken remnants, and fixes the
ptrace() hang in the process.
Noticed and bisected by Duane Griffin, who also supplied a test-case
(quoth Nick: "Well that's probably the best bug report I've ever had,
thanks Duane!").
Cc: Duane Griffin <duaneg@dghda.com>
Acked-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
mm/filemap.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1312,7 +1312,7 @@ int filemap_fault(struct vm_area_struct
size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
if (vmf->pgoff >= size)
- goto outside_data_content;
+ return VM_FAULT_SIGBUS;
/* If we don't want any read-ahead, don't bother */
if (VM_RandomReadHint(vma))
@@ -1389,7 +1389,7 @@ retry_find:
if (unlikely(vmf->pgoff >= size)) {
unlock_page(page);
page_cache_release(page);
- goto outside_data_content;
+ return VM_FAULT_SIGBUS;
}
/*
@@ -1400,15 +1400,6 @@ retry_find:
vmf->page = page;
return ret | VM_FAULT_LOCKED;
-outside_data_content:
- /*
- * An external ptracer can access pages that normally aren't
- * accessible..
- */
- if (vma->vm_mm == current->mm)
- return VM_FAULT_SIGBUS;
-
- /* Fall through to the non-read-ahead case */
no_cached_page:
/*
* We're only likely to ever get here if MADV_RANDOM is in
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 04/13] param_sysfs_builtin memchr argument fix
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (2 preceding siblings ...)
2007-11-15 6:09 ` [patch 03/13] Remove broken ptrace() special-case code from file mapping Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 16:11 ` Chuck Ebbert
2007-11-15 6:09 ` [patch 05/13] HOWTO: update ja_JP/HOWTO with latest changes Greg KH
` (8 subsequent siblings)
12 siblings, 1 reply; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Dave Young, Greg KH
[-- Attachment #1: param_sysfs_builtin-memchr-argument-fix.patch --]
[-- Type: text/plain, Size: 3032 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dave Young <hidave.darkstar@gmail.com>
patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.
If memchr argument is longer than strlen(kp->name), there will be some
weird result.
It will casuse duplicate filenames in sysfs for the "nousb". kernel
warning messages are as bellow:
sysfs: duplicate filename 'usbcore' can not be created
WARNING: at fs/sysfs/dir.c:416 sysfs_add_one()
[<c01c4750>] sysfs_add_one+0xa0/0xe0
[<c01c4ab8>] create_dir+0x48/0xb0
[<c01c4b69>] sysfs_create_dir+0x29/0x50
[<c024e0fb>] create_dir+0x1b/0x50
[<c024e3b6>] kobject_add+0x46/0x150
[<c024e2da>] kobject_init+0x3a/0x80
[<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
[<c053b9ce>] param_sysfs_builtin+0xee/0x130
[<c053ba33>] param_sysfs_init+0x23/0x60
[<c024d062>] __next_cpu+0x12/0x20
[<c052aa30>] kernel_init+0x0/0xb0
[<c052aa30>] kernel_init+0x0/0xb0
[<c052a856>] do_initcalls+0x46/0x1e0
[<c01bdb12>] create_proc_entry+0x52/0x90
[<c0158d4c>] register_irq_proc+0x9c/0xc0
[<c01bda94>] proc_mkdir_mode+0x34/0x50
[<c052aa30>] kernel_init+0x0/0xb0
[<c052aa92>] kernel_init+0x62/0xb0
[<c0104f83>] kernel_thread_helper+0x7/0x14
=======================
kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory.
[<c024e466>] kobject_add+0xf6/0x150
[<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
[<c053b9ce>] param_sysfs_builtin+0xee/0x130
[<c053ba33>] param_sysfs_init+0x23/0x60
[<c024d062>] __next_cpu+0x12/0x20
[<c052aa30>] kernel_init+0x0/0xb0
[<c052aa30>] kernel_init+0x0/0xb0
[<c052a856>] do_initcalls+0x46/0x1e0
[<c01bdb12>] create_proc_entry+0x52/0x90
[<c0158d4c>] register_irq_proc+0x9c/0xc0
[<c01bda94>] proc_mkdir_mode+0x34/0x50
[<c052aa30>] kernel_init+0x0/0xb0
[<c052aa92>] kernel_init+0x62/0xb0
[<c0104f83>] kernel_thread_helper+0x7/0x14
=======================
Module 'usbcore' failed to be added to sysfs, error number -17
The system will be unstable now.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/params.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -595,11 +595,17 @@ static void __init param_sysfs_builtin(v
for (i=0; i < __stop___param - __start___param; i++) {
char *dot;
+ size_t kplen;
kp = &__start___param[i];
+ kplen = strlen(kp->name);
/* We do not handle args without periods. */
- dot = memchr(kp->name, '.', MAX_KBUILD_MODNAME);
+ if (kplen > MAX_KBUILD_MODNAME) {
+ DEBUGP("kernel parameter name is too long: %s\n", kp->name);
+ continue;
+ }
+ dot = memchr(kp->name, '.', kplen);
if (!dot) {
DEBUGP("couldn't find period in %s\n", kp->name);
continue;
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 05/13] HOWTO: update ja_JP/HOWTO with latest changes
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (3 preceding siblings ...)
2007-11-15 6:09 ` [patch 04/13] param_sysfs_builtin memchr argument fix Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 06/13] SLUB: Fix memory leak by not reusing cpu_slab Greg KH
` (7 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Tsugikazu Shibata
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: howto-update-ja_jp-howto-with-latest-changes.patch --]
[-- Type: text/plain; charset=unknown-8bit, Size: 17768 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tsugikazu Shibata <tshibata@ab.jp.nec.co>
patch 3b6662f192fc521b9657f63e68d20ec99979dae6 upstream.
Here is another sync patch of Documentation/ja_JP/HOWTO
Japanese developer sent me some cosmetic changes and also follow
changes of HOWTO
Cross reference URL (sosdg.org/qiyong/lxr)
known_regression explanations on kernel dev. process
Signed-off-by: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Documentation/ja_JP/HOWTO | 84 ++++++++++++++++++++++++----------------------
1 file changed, 45 insertions(+), 39 deletions(-)
--- a/Documentation/ja_JP/HOWTO
+++ b/Documentation/ja_JP/HOWTO
@@ -1,4 +1,4 @@
-NOTE:
+NOTE:
This is a version of Documentation/HOWTO translated into Japanese.
This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
and the JF Project team <www.linux.or.jp/JF>.
@@ -11,14 +11,14 @@ for non English (read: Japanese) speaker
fork. So if you have any comments or updates for this file, please try
to update the original English file first.
-Last Updated: 2007/07/18
+Last Updated: 2007/09/23
==================================
ããã¯ã
-linux-2.6.22/Documentation/HOWTO
+linux-2.6.23/Documentation/HOWTO
ã®å訳ã§ãã
翻訳å£ä½ï¼ JF ããã¸ã§ã¯ã < http://www.linux.or.jp/JF/ >
-翻訳æ¥ï¼ 2007/07/16
+翻訳æ¥ï¼ 2007/09/19
翻訳è
ï¼ Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
æ ¡æ£è
ï¼ æ¾åãã <nbh--mats at nifty dot com>
å°æ é
å
¸ãã (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@@ -27,6 +27,7 @@ linux-2.6.22/Documentation/HOWTO
éå£ãã (Kenji Noguchi) <tokyo246 at gmail dot com>
æ²³å
ãã (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
岩æ¬ãã (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
+ å
ç°ãã (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
==================================
Linux ã«ã¼ãã«éçºã®ããæ¹
@@ -40,7 +41,7 @@ Linux ã«ã¼ãã«éçºã³ãã¥ããã
æå©ãã«ãªãã¾ãã
ããããã®ããã¥ã¡ã³ãã®ã©ãããå¤ããªã£ã¦ããå ´åã«ã¯ããã®ããã¥ã¡ã³
-ãã®æå¾ã«ãªã¹ãããã¡ã³ããã¼ã«ããããéã£ã¦ãã ããã
+ãã®æå¾ã«ãªã¹ãããã¡ã³ããã«ããããéã£ã¦ãã ããã
ã¯ããã«
---------
@@ -59,7 +60,7 @@ Linux ã«ã¼ãã«éçºã³ãã¥ããã
ãã«éçºè
ã«ã¯å¿
è¦ã§ããã¢ã¼ããã¯ãã£åãã®ä½ã¬ãã«é¨åã®éçºãããã®
ã§ãªããã°ã(ã©ããªã¢ã¼ããã¯ãã£ã§ã)ã¢ã»ã³ããª(訳注: è¨èª)ã¯å¿
è¦ãã
ã¾ããã以ä¸ã®æ¬ã¯ãC è¨èªã®ååãªç¥èãä½å¹´ãã®çµé¨ã«åã£ã¦ä»£ãããã®
-ã§ã¯ããã¾ããããå°ãªãã¨ããªãã¡ã¬ã³ã¹ã¨ãã¦ã¯ããæ¬ã§ãã
+ã§ã¯ããã¾ããããå°ãªãã¨ããªãã¡ã¬ã³ã¹ã¨ãã¦ã¯è¯ãæ¬ã§ãã
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
-ãããã°ã©ãã³ã°è¨èªï¼£ç¬¬2çã(B.W. ã«ã¼ããã³/D.M. ãªããã¼è ç³ç°æ´ä¹
訳) [å
±ç«åºç]
- "Practical C Programming" by Steve Oualline [O'Reilly]
@@ -76,7 +77,7 @@ Linux ã«ã¼ãã«éçºã³ãã¥ããã
ã¨ãã©ããã«ã¼ãã«ããã¼ã«ãã§ã¤ã³ã C è¨èªæ¡å¼µã«ç½®ãã¦ããåæãã©ã
ãªã£ã¦ããã®ããããã«ãããã¨ããããã¾ããæ®å¿µãªãã¨ã«æ±ºå®çãªãªãã¡
ã¬ã³ã¹ã¯åå¨ãã¾ãããæ
å ±ãå¾ãã«ã¯ãgcc ã® info ãã¼ã¸( info gcc )ã
-ã¿ã¦ãã ããã
+è¦ã¦ãã ããã
ããªãã¯æ¢åã®éçºã³ãã¥ããã£ã¨ä¸ç·ã«ä½æ¥ããæ¹æ³ãå¦ã¼ãã¨ãã¦ããã
ã¨ã«çæãã¦ãã ããããã®ã³ãã¥ããã£ã¯ãã³ã¼ãã£ã³ã°ãã¹ã¿ã¤ã«ã
@@ -92,7 +93,7 @@ Linux ã«ã¼ãã«éçºã³ãã¥ããã
Linux ã«ã¼ãã«ã®ã½ã¼ã¹ã³ã¼ã㯠GPL ã©ã¤ã»ã³ã¹ã®ä¸ã§ãªãªã¼ã¹ããã¦ãã¾
ããã©ã¤ã»ã³ã¹ã®è©³ç´°ã«ã¤ãã¦ã¯ãã½ã¼ã¹ããªã¼ã®ã¡ã¤ã³ãã£ã¬ã¯ããªã«åå¨
-ãããCOPYING ã®ãã¡ã¤ã«ãã¿ã¦ãã ãããããã©ã¤ã»ã³ã¹ã«ã¤ãã¦ããã«è³ª
+ãããCOPYING ã®ãã¡ã¤ã«ãè¦ã¦ãã ãããããã©ã¤ã»ã³ã¹ã«ã¤ãã¦ããã«è³ª
åãããã°ãLinux Kernel ã¡ã¼ãªã³ã°ãªã¹ãã«è³ªåããã®ã§ã¯ãªããã©ãã
æ³å¾å®¶ã«ç¸è«ãã¦ãã ãããã¡ã¼ãªã³ã°ãªã¹ãã®äººéã¯æ³å¾å®¶ã§ã¯ãªããæ³ç
åé¡ã«ã¤ãã¦ã¯å½¼ãã®å£°æã¯ãã¦ã«ããã¹ãã§ã¯ããã¾ããã
@@ -109,7 +110,8 @@ Linux ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã¯å
æ°ããããã¥ã¡ã³ããã¡ã¤ã«ã追å ãããã¨ãå§ãã¾ãã
ã«ã¼ãã«ã®å¤æ´ããã«ã¼ãã«ãã¦ã¼ã¶ç©ºéã«å
¬éãã¦ããã¤ã³ã¿ã¼ãã§ã¤ã¹ã®
å¤æ´ãå¼ãèµ·ããå ´åããã®å¤æ´ã説æããããã¥ã¢ã«ãã¼ã¸ã®ããããæ
å ±
-ãããã¥ã¢ã«ãã¼ã¸ã®ã¡ã³ãã mtk-manpages@gmx.net ã«éããã¨ãå§ãã¾ãã
+ãããã¥ã¢ã«ãã¼ã¸ã®ã¡ã³ãã mtk-manpages@gmx.net ã«éããã¨ãå§ãã¾
+ãã
以ä¸ã¯ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã«å«ã¾ãã¦ããèªãã§ããã¹ããã¡ã¤ã«ã®ä¸è¦§ã§
ã-
@@ -117,7 +119,7 @@ Linux ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã¯å
README
ãã®ãã¡ã¤ã«ã¯ Linuxã«ã¼ãã«ã®ç°¡åãªèæ¯ã¨ã«ã¼ãã«ãè¨å®(訳注
configure )ããçæ(訳注 build )ããããã«å¿
è¦ãªãã¨ã¯ä½ããæ¸ãã
- ã¦ãã¾ããã«ã¼ãã«ã«é¢ãã¦åãã¦ã®äººã¯ããããã¹ã¿ã¼ãããã¨ããã§
+ ã¦ãã¾ããã«ã¼ãã«ã«é¢ãã¦åãã¦ã®äººã¯ããããã¹ã¿ã¼ãããã¨è¯ãã§
ãããã
Documentation/Changes
@@ -128,7 +130,7 @@ Linux ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã¯å
Documentation/CodingStyle
ãã㯠Linux ã«ã¼ãã«ã®ã³ã¼ãã£ã³ã°ã¹ã¿ã¤ã«ã¨èæ¯ã«ããçç±ãè¨è¿°
ãã¦ãã¾ããå
¨ã¦ã®æ°ããã³ã¼ãã¯ãã®ããã¥ã¡ã³ãã«ããã¬ã¤ãã©ã¤ã³
- ã«å¾ã£ã¦ãããã¨ãæå¾
ããã¦ãã¾ãã大é¨åã®ã¡ã³ããã¼ã¯ãããã®ã«ã¼
+ ã«å¾ã£ã¦ãããã¨ãæå¾
ããã¦ãã¾ãã大é¨åã®ã¡ã³ããã¯ãããã®ã«ã¼
ã«ã«å¾ã£ã¦ãããã®ã ããåãä»ããå¤ãã®äººã¯æ£ããã¹ã¿ã¤ã«ã®ã³ã¼ã
ã ããã¬ãã¥ã¼ãã¾ãã
@@ -168,16 +170,16 @@ Linux ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã¯å
æ¯æ´ãã¦ãã ããã
Documentation/ManagementStyle
- ãã®ããã¥ã¡ã³ã㯠Linux ã«ã¼ãã«ã®ã¡ã³ããã¼éãã©ãè¡åãããã
+ ãã®ããã¥ã¡ã³ã㯠Linux ã«ã¼ãã«ã®ã¡ã³ããéãã©ãè¡åãããã
å½¼ãã®ææ³ã®èæ¯ã«ããå
±æããã¦ããç²¾ç¥ã«ã¤ãã¦è¨è¿°ãã¦ãã¾ããã
ãã¯ã«ã¼ãã«éçºã®åå¿è
ãªãï¼ãããã¯ãåã«èå³ãããã ãã®äººã§ãï¼
- éè¦ã§ãããªããªããã®ããã¥ã¡ã³ãã¯ãã«ã¼ãã«ã¡ã³ããã¼éã®ç¬ç¹ãª
+ éè¦ã§ãããªããªããã®ããã¥ã¡ã³ãã¯ãã«ã¼ãã«ã¡ã³ããéã®ç¬ç¹ãª
è¡åã«ã¤ãã¦ã®å¤ãã®èª¤è§£ãæ··ä¹±ã解æ¶ããããã§ãã
Documentation/stable_kernel_rules.txt
ãã®ãã¡ã¤ã«ã¯ã©ã®ããã« stable ã«ã¼ãã«ã®ãªãªã¼ã¹ãè¡ããããã®ã«ã¼
ã«ãè¨è¿°ããã¦ãã¾ããããã¦ãããã®ãªãªã¼ã¹ã®ä¸ã®ã©ããã§å¤æ´ãå
- ãå
¥ãã¦ãããããå ´åã«ä½ãããã°ãããã示ããã¦ãã¾ãã
+ ãå
¥ãã¦ãããããå ´åã«ä½ãããã°è¯ããã示ããã¦ãã¾ãã
Documentation/kernel-docs.txt
ããã«ã¼ãã«éçºã«ä»éããå¤é¨ããã¥ã¡ã³ãã®ãªã¹ãã§ããããããªãã
@@ -218,9 +220,9 @@ web ãµã¤ãã«ã¯ãã³ã¼ãã®æ§æ
ããã«ã¯ãã¾ããã«ã¼ãã«ã®ã³ã³ãã¤ã«ã®ããæ¹ããããã®å½ã¦æ¹ãªã©ã®éæ¥
çãªåºæ¬æ
å ±ãè¨è¿°ããã¦ãã¾ãã
-ããªããã©ãããã¹ã¿ã¼ããã¦ãããããããªãããLinux ã«ã¼ãã«éçºã³ãã¥
+ããªããã©ãããã¹ã¿ã¼ããã¦è¯ããããããªãããLinux ã«ã¼ãã«éçºã³ãã¥
ããã£ã«åå ãã¦ä½ããããã¨ããããã¦ããå ´åã«ã¯ãLinux kernel
-Janitor's ããã¸ã§ã¯ãã«ããã°ããã§ããã -
+Janitor's ããã¸ã§ã¯ãã«ããã°è¯ãã§ããã -
http://janitor.kernelnewbies.org/
ããã¯ãã®ãããªã¹ã¿ã¼ããããã®ã«ãã£ã¦ã¤ãã®å ´æã§ããããã«ã¯ã
Linux ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã®ä¸ã«å«ã¾ããããããã«ããä¿®æ£ããªããã°ãª
@@ -243,7 +245,7 @@ Linux ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã®ä
èªå·±åç
§æ¹å¼ã§ãç´¢å¼ãã¤ãã web å½¢å¼ã§ãã½ã¼ã¹ã³ã¼ããåç
§ãããã¨ã
ã§ãã¾ãããã®ææ°ã®ç´ æ´ããã«ã¼ãã«ã³ã¼ãã®ãªãã¸ããªã¯ä»¥ä¸ã§è¦ã¤ãã
ã¾ã-
- http://sosdg.org/~coywolf/lxr/
+ http://sosdg.org/~qiyong/lxr/
éçºããã»ã¹
-----------------------
@@ -265,9 +267,9 @@ Linux ã«ã¼ãã«ã®éçºããã»ã¹ã
以ä¸ã®ã¨ãã-
- æ°ããã«ã¼ãã«ããªãªã¼ã¹ãããç´å¾ã«ã2é±éã®ç¹å¥æéãè¨ãããã
- ãã®æéä¸ã«ãã¡ã³ããã¼é㯠Linus ã«å¤§ããªå·®åãéããã¨ãã§ãã¾
- ãããã®ãããªå·®åã¯é常 -mm ã«ã¼ãã«ã«æ°é±éå«ã¾ãã¦ãããããã§
- ãã 大ããªå¤æ´ã¯ git(ã«ã¼ãã«ã®ã½ã¼ã¹ç®¡çãã¼ã«ã詳細ã¯
+ ãã®æéä¸ã«ãã¡ã³ããé㯠Linus ã«å¤§ããªå·®åãéããã¨ãã§ãã¾ãã
+ ãã®ãããªå·®åã¯é常 -mm ã«ã¼ãã«ã«æ°é±éå«ã¾ãã¦ãããããã§ãã
+ 大ããªå¤æ´ã¯ git(ã«ã¼ãã«ã®ã½ã¼ã¹ç®¡çãã¼ã«ã詳細ã¯
http://git.or.cz/ åç
§) ã使ã£ã¦éãã®ã好ã¾ããããæ¹ã§ããããã
ããã¡ã¤ã«ã®å½¢å¼ã®ã¾ã¾éãã®ã§ãååã§ãã
@@ -285,6 +287,10 @@ Linux ã«ã¼ãã«ã®éçºããã»ã¹ã
ã«å®å®ããç¶æ
ã«ããã¨å¤æããã¨ãã«ãªãªã¼ã¹ããã¾ããç®æ¨ã¯æ¯é±æ°
ãã -rc ã«ã¼ãã«ããªãªã¼ã¹ãããã¨ã§ãã
+ - 以ä¸ã® URL ã§å -rc ãªãªã¼ã¹ã«åå¨ããæ¢ç¥ã®å¾æ»ãåé¡ã®ãªã¹ã
+ ã追跡ããã¾ã-
+ http://kernelnewbies.org/known_regressions
+
- ãã®ããã»ã¹ã¯ã«ã¼ãã«ã ãæºåãã§ãããã¨èããããã¾ã§ç¶ç¶ãã¾
ãããã®ããã»ã¹ã¯ã ããã 6é±éç¶ç¶ãã¾ãã
@@ -331,8 +337,8 @@ Andrew ã¯åå¥ã®ãµãã·ã¹ãã ã«
linux-kernel ã¡ã¼ãªã³ã°ãªã¹ãã§åéãããå¤æ°ã®ãããã¨åæã«ä¸ã¤ã«ã¾
ã¨ãã¾ãã
ãã®ããªã¼ã¯æ°æ©è½ã¨ããããæ¤è¨¼ãããå ´ã¨ãªãã¾ããããæéã®éããã
-ã -mm ã«å
¥ã£ã¦ä¾¡å¤ã証æãããããAndrew ããµãã·ã¹ãã ã¡ã³ããããã¡
-ã¤ã³ã©ã¤ã³ã¸å
¥ããããã« Linus ã«ããã·ã¥ãã¾ãã
+ã -mm ã«å
¥ã£ã¦ä¾¡å¤ã証æãããããAndrew ããµãã·ã¹ãã ã¡ã³ãããã
+ã¡ã¤ã³ã©ã¤ã³ã¸å
¥ããããã« Linus ã«ããã·ã¥ãã¾ãã
ã¡ã¤ã³ã«ã¼ãã«ããªã¼ã«å«ããããã« Linus ã«éãåã«ããã¹ã¦ã®æ°ãããã
ãã -mm ããªã¼ã§ãã¹ãããããã¨ãå¼·ãæ¨å¥¨ããã¾ãã
@@ -460,7 +466,7 @@ MAINTAINERS ãã¡ã¤ã«ã«ãªã¹ããã
ãã-
å½¼ãã¯ããªãã®ãããã®è¡æ¯ã«ã³ã¡ã³ããå
¥ãããã®ã§ããã®ããã«ã¯ããã
ãããããã¾ãããããªãã®ã¡ã¼ã«ããã°ã©ã ã空ç½ãã¿ããå§ç¸®ããªããã
-ã«ç¢ºèªããæ¹ãããã§ããæåã®è¯ããã¹ãã¨ãã¦ã¯ãèªåã«ã¡ã¼ã«ãéã£ã¦
+ã«ç¢ºèªããæ¹ãè¯ãã§ããæåã®è¯ããã¹ãã¨ãã¦ã¯ãèªåã«ã¡ã¼ã«ãéã£ã¦
ã¿ã¦ããã®ããããèªåã§å½ã¦ã¦ã¿ããã¨ã§ããããããããã¾ãè¡ããªããª
ããããªãã®ã¡ã¼ã«ããã°ã©ã ãç´ãã¦ãããããæ£ããåãããã«å¤ããã¹
ãã§ãã
@@ -507,14 +513,14 @@ MAINTAINERS ãã¡ã¤ã«ã«ãªã¹ããã
ã¨ãæ®éã®ãã¨ã§ããããã¯ããªãã®ããããåãå
¥ããããªãã¨ãããã¨ã§
㯠*ããã¾ãã*ãããã¦ããªãèªèº«ã«å対ãããã¨ãæå³ããã®ã§ã *ããã¾
ãã*ãåã«èªåã®ãããã«å¯¾ãã¦ææãããåé¡ãå
¨ã¦ä¿®æ£ãã¦åéããã°
-ããã®ã§ãã
+è¯ãã®ã§ãã
ã«ã¼ãã«ã³ãã¥ããã£ã¨ä¼æ¥çµç¹ã®ã¡ãã
-----------------------------------------------------------------
ã«ã¼ãã«ã³ãã¥ããã£ã¯å¤§é¨åã®ä¼çµ±çãªä¼ç¤¾ã®éçºç°å¢ã¨ã¯ç°ã£ãããæ¹ã§
-åãã¦ãã¾ãã以ä¸ã¯åé¡ãé¿ããããã«ã§ããã¨ãããã¨ã®ã®ãªã¹ãã§ã-
+åãã¦ãã¾ãã以ä¸ã¯åé¡ãé¿ããããã«ã§ããã¨è¯ããã¨ã®ãªã¹ãã§ã-
ããªãã®ææ¡ããå¤æ´ã«ã¤ãã¦è¨ãã¨ãã®ãã¾ãè¨ãæ¹ï¼
@@ -525,7 +531,7 @@ MAINTAINERS ãã¡ã¤ã«ã«ãªã¹ããã
- "以ä¸ã¯ä¸é£ã®å°ããªããã群ã§ãã..."
- "ããã¯å
¸åçãªãã·ã³ã§ã®æ§è½ãåä¸ããã¾ã.."
- ãããæ¹ãããæªãè¨ãæ¹ï¼
+ ãããæ¹ãè¯ãæªãè¨ãæ¹ï¼
- ãã®ããæ¹ã§ AIX/ptx/Solaris ã§ã¯ã§ããã®ã§ãã§ããã¯ãã
- ç§ã¯ããã20å¹´ãã®éãã£ã¦ãããã ãã
@@ -575,10 +581,10 @@ Linux ã«ã¼ãã«ã³ãã¥ããã£ã¯ã
1) å°ãããããã¯ããªãã®ããããé©ç¨ãããè¦è¾¼ã¿ã大ãããã¾ããã«ã¼
ãã«ã®äººéã¯ããããæ£ãããã©ããã確èªããæéãå´åããããªãã
- ãã§ãã5è¡ã®ãããã¯ã¡ã³ããããã£ã1ç§è¦ãã ãã§é©ç¨ã§ãã¾ããã
- ããã500è¡ã®ãããã¯ãæ£ãããã¨ãã¬ãã¥ã¼ããã®ã«æ°æéããããã
- ããã¾ãã(æéã¯ãããã®ãµã¤ãºãªã©ã«ããææ°é¢æ°ã«æ¯ä¾ãã¦ãããã¾
- ã)
+ ãã§ãã5è¡ã®ãããã¯ã¡ã³ããããã£ã1ç§è¦ãã ãã§é©ç¨ã§ãã¾ãã
+ ãããã500è¡ã®ãããã¯ãæ£ãããã¨ãã¬ãã¥ã¼ããã®ã«æ°æéãããã
+ ãããã¾ãã(æéã¯ãããã®ãµã¤ãºãªã©ã«ããææ°é¢æ°ã«æ¯ä¾ãã¦ããã
+ ã¾ã)
å°ãããããã¯ä½ããã£ãã¨ãã«ãããã°ãã¨ã¦ãç°¡åã«ãªãã¾ãããã
ãã1å1ååãé¤ãã®ã¯ãã¨ã¦ã大ããªããããå½ã¦ãå¾ã«(ãã¤ãä½ãã
@@ -587,23 +593,23 @@ Linux ã«ã¼ãã«ã³ãã¥ããã£ã¯ã
2) å°ããããããéãã ãã§ãªããéãã¾ãã«ãæ¸ãç´ãã¦ãã·ã³ãã«ã«ã
ã(ãããã¯ãåã«é çªãå¤ããã ãã§ã)ãã¨ããã¨ã¦ãéè¦ã§ãã
-以ä¸ã¯ã«ã¼ãã«éçºè
ã® Al Viro ã®ãã¨ã話ãã§ãï¼
+以ä¸ã¯ã«ã¼ãã«éçºè
ã® Al Viro ã®ãã¨ã話ã§ãï¼
"çå¾ã®æ°å¦ã®å®¿é¡ãæ¡ç¹ããå
çã®ãã¨ãèãã¦ã¿ã¦ãã ãããå
- çã¯çå¾ã解ã«å°éããã¾ã§ã®è©¦è¡é¯èª¤ãã¿ããã¨ã¯æããªãã§ãã
- ããå
çã¯ç°¡æ½ãªæé«ã®è§£ãã¿ããã®ã§ããè¯ãçå¾ã¯ãããç¥ã£ã¦
+ çã¯çå¾ã解ã«å°éããã¾ã§ã®è©¦è¡é¯èª¤ãè¦ããã¨ã¯æããªãã§ãã
+ ããå
çã¯ç°¡æ½ãªæé«ã®è§£ãè¦ããã®ã§ããè¯ãçå¾ã¯ãããç¥ã£ã¦
ãããããã¦æçµè§£ã®åã®ä¸éä½æ¥ãæåºãããã¨ã¯æ±ºãã¦ãªãã®ã§
ã"
- ã«ã¼ãã«éçºã§ãããã¯åãã§ããã¡ã³ããã¼éã¨ã¬ãã¥ã¼ã¢éã¯ã
- åé¡ã解決ãã解ã®èå¾ã«ãªãæèããã»ã¹ãã¿ããã¨ã¯æãã¾ããã
- å½¼ãã¯åç´ã§ãããããªè§£æ±ºæ¹æ³ãã¿ããã®ã§ãã
+ ã«ã¼ãã«éçºã§ãããã¯åãã§ããã¡ã³ããéã¨ã¬ãã¥ã¼ã¢éã¯ã
+ åé¡ã解決ãã解ã®èå¾ã«ãªãæèããã»ã¹ãè¦ããã¨ã¯æãã¾ããã
+ å½¼ãã¯åç´ã§ãããããªè§£æ±ºæ¹æ³ãè¦ããã®ã§ãã
ãããããªè§£ã説æããã®ã¨ãã³ãã¥ããã£ã¨å
±ã«ä»äºãããæªè§£æ±ºã®ä»äºã
è°è«ãããã¨ã®ãã©ã³ã¹ããã¼ãããã®ã¯é£ããããããã¾ããã
ã§ããããéçºããã»ã¹ã®æ©æ段éã§æ¹åã®ããã®ãã£ã¼ãããã¯ããããã
-ãã«ããã®ãããã§ãããå¤æ´ç¹ãå°ããé¨åã«åå²ãã¦å
¨ä½ã§ã¯ã¾ã å®æã
-ã¦ããªãä»äºã(é¨åçã«)åãè¾¼ãã§ããããããã«ãããã¨ããããã¨ã§ãã
+ãã«ããã®ãè¯ãã§ãããå¤æ´ç¹ãå°ããé¨åã«åå²ãã¦å
¨ä½ã§ã¯ã¾ã å®æã
+ã¦ããªãä»äºã(é¨åçã«)åãè¾¼ãã§ããããããã«ãããã¨ãè¯ããã¨ã§ãã
ã¾ããã§ãä¸ãã£ã¦ããªããã®ãã"å°æ¥ç´ã" ãããªãããããæ¬æµã«å«ã
ã¦ãããããã«éã£ã¦ããããã¯åãä»ããããªããã¨ãç解ãã¦ãã ããã
@@ -629,7 +635,7 @@ Linux ã«ã¼ãã«ã³ãã¥ããã£ã¯ã
- ãã¹ãçµæ
ããã«ã¤ãã¦å
¨ã¦ãã©ã®ããã«ããã¹ããã«ã¤ãã¦ã®è©³ç´°ã¯ã以ä¸ã®ããã¥ã¡
-ã³ãã® ChangeLog ã»ã¯ã·ã§ã³ãã¿ã¦ãã ãã-
+ã³ãã® ChangeLog ã»ã¯ã·ã§ã³ãè¦ã¦ãã ãã-
"The Perfect Patch"
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 06/13] SLUB: Fix memory leak by not reusing cpu_slab
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (4 preceding siblings ...)
2007-11-15 6:09 ` [patch 05/13] HOWTO: update ja_JP/HOWTO with latest changes Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 07/13] writeback: dont propagate AOP_WRITEPAGE_ACTIVATE Greg KH
` (6 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Oliv?r Pint?r, Hugh Dickins, Willy Tarreau, Christoph Lameter
[-- Attachment #1: slub-fix-memory-leak-by-not-reusing-cpu_slab.patch --]
[-- Type: text/plain, Size: 1907 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Christoph Lameter <clameter@sgi.com>
patch 05aa345034de6ae9c77fb93f6a796013641d57d5 in mainline.
SLUB: Fix memory leak by not reusing cpu_slab
Fix the memory leak that may occur when we attempt to reuse a cpu_slab
that was allocated while we reenabled interrupts in order to be able to
grow a slab cache. The per cpu freelist may contain objects and in that
situation we may overwrite the per cpu freelist pointer loosing objects.
This only occurs if we find that the concurrently allocated slab fits
our allocation needs.
If we simply always deactivate the slab then the freelist will be properly
reintegrated and the memory leak will go away.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
mm/slub.c | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1501,28 +1501,8 @@ new_slab:
page = new_slab(s, gfpflags, node);
if (page) {
cpu = smp_processor_id();
- if (s->cpu_slab[cpu]) {
- /*
- * Someone else populated the cpu_slab while we
- * enabled interrupts, or we have gotten scheduled
- * on another cpu. The page may not be on the
- * requested node even if __GFP_THISNODE was
- * specified. So we need to recheck.
- */
- if (node == -1 ||
- page_to_nid(s->cpu_slab[cpu]) == node) {
- /*
- * Current cpuslab is acceptable and we
- * want the current one since its cache hot
- */
- discard_slab(s, page);
- page = s->cpu_slab[cpu];
- slab_lock(page);
- goto load_freelist;
- }
- /* New slab does not fit our expectations */
+ if (s->cpu_slab[cpu])
flush_slab(s, s->cpu_slab[cpu], cpu);
- }
slab_lock(page);
SetSlabFrozen(page);
s->cpu_slab[cpu] = page;
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 07/13] writeback: dont propagate AOP_WRITEPAGE_ACTIVATE
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (5 preceding siblings ...)
2007-11-15 6:09 ` [patch 06/13] SLUB: Fix memory leak by not reusing cpu_slab Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 08/13] splice: fix double kunmap() in vmsplice copy path Greg KH
` (5 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable, torvalds
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, akpm, alan
[-- Attachment #1: writeback-don-t-propagate-aop_writepage_activate.patch --]
[-- Type: text/plain, Size: 945 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andrew Morton <akpm@linux-foundation.org>
patch e423003028183df54f039dfda8b58c49e78c89d7 in mainline.
This is a writeback-internal marker but we're propagating it all the way back
to userspace!.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
mm/page-writeback.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -672,8 +672,10 @@ retry:
ret = (*writepage)(page, wbc, data);
- if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE))
+ if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE)) {
unlock_page(page);
+ ret = 0;
+ }
if (ret || (--(wbc->nr_to_write) <= 0))
done = 1;
if (wbc->nonblocking && bdi_write_congested(bdi)) {
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 08/13] splice: fix double kunmap() in vmsplice copy path
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (6 preceding siblings ...)
2007-11-15 6:09 ` [patch 07/13] writeback: dont propagate AOP_WRITEPAGE_ACTIVATE Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 09/13] fix the softlockup watchdog to actually work Greg KH
` (4 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Jens Axboe
[-- Attachment #1: splice-fix-double-kunmap-in-vmsplice-copy-path.patch --]
[-- Type: text/plain, Size: 2371 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jens Axboe <jens.axboe@oracle.com>
patch 6866bef40d06f7c2baac3a855b1917a8ca75456c in mainline.
The out label should not include the unmap, the only way to jump
there already has unmapped the source.
00002000
f7c21a00 00000000 00000000 c0489036 00018e32 00000002 00000000
00001000
Call Trace:
[<c0487dd9>] pipe_to_user+0xca/0xd3
[<c0488233>] __splice_from_pipe+0x53/0x1bd
[<c0454947>] ------------[ cut here ]------------
filemap_fault+0x221/0x380
[<c0487d0f>] pipe_to_user+0x0/0xd3
[<c0489036>] sys_vmsplice+0x3b7/0x422
[<c045ec3f>] kernel BUG at mm/highmem.c:206!
handle_mm_fault+0x4d5/0x8eb
[<c041ed5b>] kmap_atomic+0x1c/0x20
[<c045d33d>] unmap_vmas+0x3d1/0x584
[<c045f717>] free_pgtables+0x90/0xa0
[<c041d84b>] pgd_dtor+0x0/0x1
[<c044d665>] audit_syscall_exit+0x2aa/0x2c6
[<c0407817>] do_syscall_trace+0x124/0x169
[<c0404df2>] syscall_call+0x7/0xb
=======================
Code: 2d 00 d0 5b 00 25 00 00 e0 ff 29 invalid opcode: 0000 [#1]
c2 89 d0 c1 e8 0c 8b 14 85 a0 6c 7c c0 4a 85 d2 89 14 85 a0 6c 7c c0 74 07
31 c9 4a 75 15 eb 04 <0f> 0b eb fe 31 c9 81 3d 78 38 6d c0 78 38 6d c0 0f
95 c1 b0 01
EIP: [<c045bbc3>] kunmap_high+0x51/0x8e SS:ESP 0068:f5960df0
SMP
Modules linked in: netconsole autofs4 hidp nfs lockd nfs_acl rfcomm l2cap
bluetooth sunrpc ipv6 ib_iser rdma_cm ib_cm iw_cmib_sa ib_mad ib_core
ib_addr iscsi_tcp libiscsi scsi_transport_iscsi dm_mirror dm_multipath
dm_mod video output sbs batteryac parport_pc lp parport sg i2c_piix4
i2c_core floppy cfi_probe gen_probe scb2_flash mtd chipreg tg3 e1000 button
ide_cd serio_raw cdrom aic7xxx scsi_transport_spi sd_mod scsi_mod ext3 jbd
ehci_hcd ohci_hcd uhci_hcd
CPU: 3
EIP: 0060:[<c045bbc3>] Not tainted VLI
EFLAGS: 00010246 (2.6.23 #1)
EIP is at kunmap_high+0x51/0x8e
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/splice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1390,10 +1390,10 @@ static int pipe_to_user(struct pipe_inod
if (copy_to_user(sd->u.userptr, src + buf->offset, sd->len))
ret = -EFAULT;
+ buf->ops->unmap(pipe, buf, src);
out:
if (ret > 0)
sd->u.userptr += ret;
- buf->ops->unmap(pipe, buf, src);
return ret;
}
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 09/13] fix the softlockup watchdog to actually work
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (7 preceding siblings ...)
2007-11-15 6:09 ` [patch 08/13] splice: fix double kunmap() in vmsplice copy path Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 10/13] sched: keep utime/stime monotonic Greg KH
` (3 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable, torvalds
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, akpm, alan, mingo, jeremy
[-- Attachment #1: fix-the-softlockup-watchdog-to-actually-work.patch --]
[-- Type: text/plain, Size: 1671 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ingo Molnar <mingo@elte.hu>
patch a115d5caca1a2905ba7a32b408a6042b20179aaa in mainline.
this Xen related commit:
commit 966812dc98e6a7fcdf759cbfa0efab77500a8868
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Tue May 8 00:28:02 2007 -0700
Ignore stolen time in the softlockup watchdog
broke the softlockup watchdog to never report any lockups. (!)
print_timestamp defaults to 0, this makes the following condition
always true:
if (print_timestamp < (touch_timestamp + 1) ||
and we'll in essence never report soft lockups.
apparently the functionality of the soft lockup watchdog was never
actually tested with that patch applied ...
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/softlockup.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -80,10 +80,11 @@ void softlockup_tick(void)
print_timestamp = per_cpu(print_timestamp, this_cpu);
/* report at most once a second */
- if (print_timestamp < (touch_timestamp + 1) ||
- did_panic ||
- !per_cpu(watchdog_task, this_cpu))
+ if ((print_timestamp >= touch_timestamp &&
+ print_timestamp < (touch_timestamp + 1)) ||
+ did_panic || !per_cpu(watchdog_task, this_cpu)) {
return;
+ }
/* do not print during early bootup: */
if (unlikely(system_state != SYSTEM_RUNNING)) {
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 10/13] sched: keep utime/stime monotonic
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (8 preceding siblings ...)
2007-11-15 6:09 ` [patch 09/13] fix the softlockup watchdog to actually work Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 11/13] Fix compat futex hangs Greg KH
` (2 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable, Greg KH
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Balbir Singh, Peter Zijlstra, Frans Pop
[-- Attachment #1: sched-keep-utime-stime-monotonic.patch --]
[-- Type: text/plain, Size: 2337 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Frans Pop <elendil@planet.nl>
sched: keep utime/stime monotonic
cpustats use utime/stime as a ratio against sum_exec_runtime, as a
consequence it can happen - when the ratio changes faster than time
accumulates - that either can be appear to go backwards.
Combined backport for 2.6.23 of the following patches from mainline:
commit 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
sched: keep utime/stime monotonic
commit 9301899be75b464ef097f0b5af7af6d9bd8f68a7
Author: Balbir Singh <balbir@linux.vnet.ibm.com>
sched: fix /proc/<PID>/stat stime/utime monotonicity, part 2
Signed-off-by: Frans Pop <elendil@planet.nl>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/proc/array.c | 6 ++++--
include/linux/sched.h | 1 +
kernel/fork.c | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -351,7 +351,8 @@ static cputime_t task_utime(struct task_
}
utime = (clock_t)temp;
- return clock_t_to_cputime(utime);
+ p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime));
+ return p->prev_utime;
}
static cputime_t task_stime(struct task_struct *p)
@@ -366,7 +367,8 @@ static cputime_t task_stime(struct task_
stime = nsec_to_clock_t(p->se.sum_exec_runtime) -
cputime_to_clock_t(task_utime(p));
- return clock_t_to_cputime(stime);
+ p->prev_stime = max(p->prev_stime, clock_t_to_cputime(stime));
+ return p->prev_stime;
}
#endif
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1022,6 +1022,7 @@ struct task_struct {
unsigned int rt_priority;
cputime_t utime, stime;
+ cputime_t prev_utime, prev_stime;
unsigned long nvcsw, nivcsw; /* context switch counts */
struct timespec start_time; /* monotonic time */
struct timespec real_start_time; /* boot based time */
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1045,6 +1045,8 @@ static struct task_struct *copy_process(
p->utime = cputime_zero;
p->stime = cputime_zero;
+ p->prev_utime = cputime_zero;
+ p->prev_stime = cputime_zero;
#ifdef CONFIG_TASK_XACCT
p->rchar = 0; /* I/O counter: bytes read */
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 11/13] Fix compat futex hangs.
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (9 preceding siblings ...)
2007-11-15 6:09 ` [patch 10/13] sched: keep utime/stime monotonic Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 12/13] fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE Greg KH
2007-11-15 6:09 ` [patch 13/13] BLOCK: Fix bad sharing of tag busy list on queues with shared tag maps Greg KH
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan, bunk,
David S. Miller
[-- Attachment #1: fix-compat-futex-hangs.patch --]
[-- Type: text/plain, Size: 3259 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Miller <davem@davemloft.net>
[FUTEX]: Fix address computation in compat code.
[ Upstream commit: 3c5fd9c77d609b51c0bab682c9d40cbb496ec6f1 ]
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:
(void __user *)entry + futex_offset
'entry' is a 'struct robust_list __user *', and
'futex_offset' is a 'compat_long_t' (typically a 's32').
Things explode if the 32-bit sign bit is set in futex_offset.
Type promotion sign extends futex_offset to a 64-bit value before
adding it to 'entry'.
This triggered a problem on sparc64 running 32-bit applications which
would lock up a cpu looping forever in the fault handling for the
userspace load in handle_futex_death().
Compat userspace runs with address masking (wherein the cpu zeros out
the top 32-bits of every effective address given to a memory operation
instruction) so the sparc64 fault handler accounts for this by
zero'ing out the top 32-bits of the fault address too.
Since the kernel properly uses the compat_uptr interfaces, kernel side
accesses to compat userspace work too since they will only use
addresses with the top 32-bit clear.
Because of this compat futex layer bug we get into the following loop
when executing the get_user() load near the top of handle_futex_death():
1) load from address '0xfffffffff7f16bd8', FAULT
2) fault handler clears upper 32-bits, processes fault
for address '0xf7f16bd8' which succeeds
3) goto #1
I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
for their tireless efforts helping me track down this bug.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/futex_compat.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -29,6 +29,15 @@ fetch_robust_entry(compat_uptr_t *uentry
return 0;
}
+static void __user *futex_uaddr(struct robust_list *entry,
+ compat_long_t futex_offset)
+{
+ compat_uptr_t base = ptr_to_compat(entry);
+ void __user *uaddr = compat_ptr(base + futex_offset);
+
+ return uaddr;
+}
+
/*
* Walk curr->robust_list (very carefully, it's a userspace list!)
* and mark any locks found there dead, and notify any waiters.
@@ -75,11 +84,13 @@ void compat_exit_robust_list(struct task
* A pending lock might already be on the list, so
* dont process it twice:
*/
- if (entry != pending)
- if (handle_futex_death((void __user *)entry + futex_offset,
- curr, pi))
- return;
+ if (entry != pending) {
+ void __user *uaddr = futex_uaddr(entry,
+ futex_offset);
+ if (handle_futex_death(uaddr, curr, pi))
+ return;
+ }
if (rc)
return;
uentry = next_uentry;
@@ -93,9 +104,11 @@ void compat_exit_robust_list(struct task
cond_resched();
}
- if (pending)
- handle_futex_death((void __user *)pending + futex_offset,
- curr, pip);
+ if (pending) {
+ void __user *uaddr = futex_uaddr(pending, futex_offset);
+
+ handle_futex_death(uaddr, curr, pip);
+ }
}
asmlinkage long
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 12/13] fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (10 preceding siblings ...)
2007-11-15 6:09 ` [patch 11/13] Fix compat futex hangs Greg KH
@ 2007-11-15 6:09 ` Greg KH
2007-11-15 6:09 ` [patch 13/13] BLOCK: Fix bad sharing of tag busy list on queues with shared tag maps Greg KH
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable, torvalds
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, akpm, alan, penberg, hugh, ezk
[-- Attachment #1: fix-tmpfs-bug-and-aop_writepage_activate.patch --]
[-- Type: text/plain, Size: 2545 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Hugh Dickins <hugh@veritas.com>
patch 487e9bf25cbae11b131d6a14bdbb3a6a77380837 in mainline.
It's possible to provoke unionfs (not yet in mainline, though in mm and
some distros) to hit shmem_writepage's BUG_ON(page_mapped(page)). I expect
it's possible to provoke the 2.6.23 ecryptfs in the same way (but the
2.6.24 ecryptfs no longer calls lower level's ->writepage).
This came to light with the recent find that AOP_WRITEPAGE_ACTIVATE could
leak from tmpfs via write_cache_pages and unionfs to userspace. There's
already a fix (e423003028183df54f039dfda8b58c49e78c89d7 - writeback: don't
propagate AOP_WRITEPAGE_ACTIVATE) in the tree for that, and it's okay so
far as it goes; but insufficient because it doesn't address the underlying
issue, that shmem_writepage expects to be called only by vmscan (relying on
backing_dev_info capabilities to prevent the normal writeback path from
ever approaching it).
That's an increasingly fragile assumption, and ramdisk_writepage (the other
source of AOP_WRITEPAGE_ACTIVATEs) is already careful to check
wbc->for_reclaim before returning it. Make the same check in
shmem_writepage, thereby sidestepping the page_mapped BUG also.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: Erez Zadok <ezk@cs.sunysb.edu>
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
mm/shmem.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -916,6 +916,21 @@ static int shmem_writepage(struct page *
struct inode *inode;
BUG_ON(!PageLocked(page));
+ /*
+ * shmem_backing_dev_info's capabilities prevent regular writeback or
+ * sync from ever calling shmem_writepage; but a stacking filesystem
+ * may use the ->writepage of its underlying filesystem, in which case
+ * we want to do nothing when that underlying filesystem is tmpfs
+ * (writing out to swap is useful as a response to memory pressure, but
+ * of no use to stabilize the data) - just redirty the page, unlock it
+ * and claim success in this case. AOP_WRITEPAGE_ACTIVATE, and the
+ * page_mapped check below, must be avoided unless we're in reclaim.
+ */
+ if (!wbc->for_reclaim) {
+ set_page_dirty(page);
+ unlock_page(page);
+ return 0;
+ }
BUG_ON(page_mapped(page));
mapping = page->mapping;
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* [patch 13/13] BLOCK: Fix bad sharing of tag busy list on queues with shared tag maps
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
` (11 preceding siblings ...)
2007-11-15 6:09 ` [patch 12/13] fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE Greg KH
@ 2007-11-15 6:09 ` Greg KH
12 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 6:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan,
Jens Axboe
[-- Attachment #1: block-fix-bad-sharing-of-tag-busy-list-on-queues-with-shared-tag-maps.patch --]
[-- Type: text/plain, Size: 3261 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jens Axboe <jens.axboe@oracle.com>
patch 6eca9004dfcb274a502438a591df5b197690afb1 in mainline.
For the locking to work, only the tag map and tag bit map may be shared
(incidentally, I was just explaining this to Nick yesterday, but I
apparently didn't review the code well enough myself). But we also share
the busy list! The busy_list must be queue private, or we need a
block_queue_tag covering lock as well.
So we have to move the busy_list to the queue. This'll work fine, and
it'll actually also fix a problem with blk_queue_invalidate_tags() which
will invalidate tags across all shared queues. This is a bit confusing,
the low level driver should call it for each queue seperately since
otherwise you cannot kill tags on just a single queue for eg a hard
drive that stops responding. Since the function has no callers
currently, it's not an issue.
This is fixed with commit 6eca9004dfcb274a502438a591df5b197690afb1 in
Linus' tree.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
block/ll_rw_blk.c | 8 +++-----
include/linux/blkdev.h | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -819,7 +819,6 @@ static int __blk_free_tags(struct blk_qu
retval = atomic_dec_and_test(&bqt->refcnt);
if (retval) {
BUG_ON(bqt->busy);
- BUG_ON(!list_empty(&bqt->busy_list));
kfree(bqt->tag_index);
bqt->tag_index = NULL;
@@ -931,7 +930,6 @@ static struct blk_queue_tag *__blk_queue
if (init_tag_map(q, tags, depth))
goto fail;
- INIT_LIST_HEAD(&tags->busy_list);
tags->busy = 0;
atomic_set(&tags->refcnt, 1);
return tags;
@@ -982,6 +980,7 @@ int blk_queue_init_tags(struct request_q
*/
q->queue_tags = tags;
q->queue_flags |= (1 << QUEUE_FLAG_QUEUED);
+ INIT_LIST_HEAD(&q->tag_busy_list);
return 0;
fail:
kfree(tags);
@@ -1152,7 +1151,7 @@ int blk_queue_start_tag(struct request_q
rq->tag = tag;
bqt->tag_index[tag] = rq;
blkdev_dequeue_request(rq);
- list_add(&rq->queuelist, &bqt->busy_list);
+ list_add(&rq->queuelist, &q->tag_busy_list);
bqt->busy++;
return 0;
}
@@ -1173,11 +1172,10 @@ EXPORT_SYMBOL(blk_queue_start_tag);
**/
void blk_queue_invalidate_tags(struct request_queue *q)
{
- struct blk_queue_tag *bqt = q->queue_tags;
struct list_head *tmp, *n;
struct request *rq;
- list_for_each_safe(tmp, n, &bqt->busy_list) {
+ list_for_each_safe(tmp, n, &q->tag_busy_list) {
rq = list_entry_rq(tmp);
if (rq->tag == -1) {
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -356,7 +356,6 @@ enum blk_queue_state {
struct blk_queue_tag {
struct request **tag_index; /* map of busy tags */
unsigned long *tag_map; /* bit map of free/busy tags */
- struct list_head busy_list; /* fifo list of busy tags */
int busy; /* current depth */
int max_depth; /* what we will send to device */
int real_max_depth; /* what the array can hold */
@@ -451,6 +450,7 @@ struct request_queue
unsigned int dma_alignment;
struct blk_queue_tag *queue_tags;
+ struct list_head tag_busy_list;
unsigned int nr_sorted;
unsigned int in_flight;
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch 04/13] param_sysfs_builtin memchr argument fix
2007-11-15 6:09 ` [patch 04/13] param_sysfs_builtin memchr argument fix Greg KH
@ 2007-11-15 16:11 ` Chuck Ebbert
2007-11-15 17:58 ` Greg KH
0 siblings, 1 reply; 19+ messages in thread
From: Chuck Ebbert @ 2007-11-15 16:11 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Dave Jones, Chuck Wolber,
Chris Wedgwood, Michael Krufky, Domenico Andreoli, torvalds,
akpm, alan, Dave Young, Greg KH
On 11/15/2007 01:09 AM, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> From: Dave Young <hidave.darkstar@gmail.com>
>
> patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.
>
> If memchr argument is longer than strlen(kp->name), there will be some
> weird result.
>
> It will casuse duplicate filenames in sysfs for the "nousb". kernel
> warning messages are as bellow:
>
Needs an additional fix:
Commit: 22800a2830ec07e7cc5c837999890ac47cc7f5de
fix param_sysfs_builtin name length check
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch 04/13] param_sysfs_builtin memchr argument fix
2007-11-15 16:11 ` Chuck Ebbert
@ 2007-11-15 17:58 ` Greg KH
2007-11-15 20:46 ` Chuck Ebbert
0 siblings, 1 reply; 19+ messages in thread
From: Greg KH @ 2007-11-15 17:58 UTC (permalink / raw)
To: Chuck Ebbert
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Dave Jones, Chuck Wolber,
Chris Wedgwood, Michael Krufky, Domenico Andreoli, torvalds,
akpm, alan, Dave Young, Greg KH
On Thu, Nov 15, 2007 at 11:11:59AM -0500, Chuck Ebbert wrote:
> On 11/15/2007 01:09 AM, Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> > From: Dave Young <hidave.darkstar@gmail.com>
> >
> > patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.
> >
> > If memchr argument is longer than strlen(kp->name), there will be some
> > weird result.
> >
> > It will casuse duplicate filenames in sysfs for the "nousb". kernel
> > warning messages are as bellow:
> >
>
> Needs an additional fix:
>
> Commit: 22800a2830ec07e7cc5c837999890ac47cc7f5de
> fix param_sysfs_builtin name length check
That just went in yesterday, right? If so, it will have to wait until
the next -stable review cycle, unless it's totally broken without that
change.
Is it?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch 04/13] param_sysfs_builtin memchr argument fix
2007-11-15 17:58 ` Greg KH
@ 2007-11-15 20:46 ` Chuck Ebbert
2007-11-15 21:20 ` Jan Kiszka
0 siblings, 1 reply; 19+ messages in thread
From: Chuck Ebbert @ 2007-11-15 20:46 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Dave Jones, Chuck Wolber,
Chris Wedgwood, Michael Krufky, Domenico Andreoli, torvalds,
akpm, alan, Dave Young, Greg KH, Jan Kiszka
On 11/15/2007 12:58 PM, Greg KH wrote:
> On Thu, Nov 15, 2007 at 11:11:59AM -0500, Chuck Ebbert wrote:
>> On 11/15/2007 01:09 AM, Greg KH wrote:
>>> -stable review patch. If anyone has any objections, please let us know.
>>>
>>> ------------------
>>> From: Dave Young <hidave.darkstar@gmail.com>
>>>
>>> patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.
>>>
>>> If memchr argument is longer than strlen(kp->name), there will be some
>>> weird result.
>>>
>>> It will casuse duplicate filenames in sysfs for the "nousb". kernel
>>> warning messages are as bellow:
>>>
>> Needs an additional fix:
>>
>> Commit: 22800a2830ec07e7cc5c837999890ac47cc7f5de
>> fix param_sysfs_builtin name length check
>
> That just went in yesterday, right? If so, it will have to wait until
> the next -stable review cycle, unless it's totally broken without that
> change.
>
> Is it?
>
Yeah, pretty much AFAICT. Maybe Jan can say exactly what happened, but
it looks like the patch would cause more problems than it solves.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch 04/13] param_sysfs_builtin memchr argument fix
2007-11-15 20:46 ` Chuck Ebbert
@ 2007-11-15 21:20 ` Jan Kiszka
2007-11-15 23:58 ` Greg KH
0 siblings, 1 reply; 19+ messages in thread
From: Jan Kiszka @ 2007-11-15 21:20 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Greg KH, linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Dave Jones, Chuck Wolber,
Chris Wedgwood, Michael Krufky, Domenico Andreoli, torvalds,
akpm, alan, Dave Young, Greg KH
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
Chuck Ebbert wrote:
> On 11/15/2007 12:58 PM, Greg KH wrote:
>> On Thu, Nov 15, 2007 at 11:11:59AM -0500, Chuck Ebbert wrote:
>>> On 11/15/2007 01:09 AM, Greg KH wrote:
>>>> -stable review patch. If anyone has any objections, please let us know.
>>>>
>>>> ------------------
>>>> From: Dave Young <hidave.darkstar@gmail.com>
>>>>
>>>> patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.
>>>>
>>>> If memchr argument is longer than strlen(kp->name), there will be some
>>>> weird result.
>>>>
>>>> It will casuse duplicate filenames in sysfs for the "nousb". kernel
>>>> warning messages are as bellow:
>>>>
>>> Needs an additional fix:
>>>
>>> Commit: 22800a2830ec07e7cc5c837999890ac47cc7f5de
>>> fix param_sysfs_builtin name length check
>> That just went in yesterday, right? If so, it will have to wait until
>> the next -stable review cycle, unless it's totally broken without that
>> change.
>>
>> Is it?
>>
>
> Yeah, pretty much AFAICT. Maybe Jan can say exactly what happened, but
> it looks like the patch would cause more problems than it solves.
>
If you have a module parameter like
"my_module.uses_long_parameter_names", Dave's patch caused it to be
rejected if that module was built into the kernel, although "my_module"
is far shorter than MAX_KBUILD_MODNAME, thus perfectly legal.
I noticed this with out-of-tree stuff, but I would bet in-tree users are
affected as well. Hmm... e.g. "nf_conntrack.expect_hashsize" should not
longer exist if nf_conntrack is non-modular.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [patch 04/13] param_sysfs_builtin memchr argument fix
2007-11-15 21:20 ` Jan Kiszka
@ 2007-11-15 23:58 ` Greg KH
0 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2007-11-15 23:58 UTC (permalink / raw)
To: Jan Kiszka
Cc: Chuck Ebbert, Greg KH, linux-kernel, stable, Justin Forbes,
Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap, Dave Jones,
Chuck Wolber, Chris Wedgwood, Michael Krufky, Domenico Andreoli,
torvalds, akpm, alan, Dave Young
On Thu, Nov 15, 2007 at 10:20:47PM +0100, Jan Kiszka wrote:
> Chuck Ebbert wrote:
> > On 11/15/2007 12:58 PM, Greg KH wrote:
> >> On Thu, Nov 15, 2007 at 11:11:59AM -0500, Chuck Ebbert wrote:
> >>> On 11/15/2007 01:09 AM, Greg KH wrote:
> >>>> -stable review patch. If anyone has any objections, please let us know.
> >>>>
> >>>> ------------------
> >>>> From: Dave Young <hidave.darkstar@gmail.com>
> >>>>
> >>>> patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.
> >>>>
> >>>> If memchr argument is longer than strlen(kp->name), there will be some
> >>>> weird result.
> >>>>
> >>>> It will casuse duplicate filenames in sysfs for the "nousb". kernel
> >>>> warning messages are as bellow:
> >>>>
> >>> Needs an additional fix:
> >>>
> >>> Commit: 22800a2830ec07e7cc5c837999890ac47cc7f5de
> >>> fix param_sysfs_builtin name length check
> >> That just went in yesterday, right? If so, it will have to wait until
> >> the next -stable review cycle, unless it's totally broken without that
> >> change.
> >>
> >> Is it?
> >>
> >
> > Yeah, pretty much AFAICT. Maybe Jan can say exactly what happened, but
> > it looks like the patch would cause more problems than it solves.
> >
>
> If you have a module parameter like
> "my_module.uses_long_parameter_names", Dave's patch caused it to be
> rejected if that module was built into the kernel, although "my_module"
> is far shorter than MAX_KBUILD_MODNAME, thus perfectly legal.
>
> I noticed this with out-of-tree stuff, but I would bet in-tree users are
> affected as well. Hmm... e.g. "nf_conntrack.expect_hashsize" should not
> longer exist if nf_conntrack is non-modular.
Ok, that makes sense, I've added your patch to the queue to go into the
next release with this original patch.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2007-11-16 0:11 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20071115042610.731859958@mini.kroah.org>
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
2007-11-15 6:09 ` [patch 01/13] lockdep: fix mismatched lockdep_depth/curr_chain_hash Greg KH
2007-11-15 6:09 ` [patch 02/13] locks: fix possible infinite loop in posix deadlock detection Greg KH
2007-11-15 6:09 ` [patch 03/13] Remove broken ptrace() special-case code from file mapping Greg KH
2007-11-15 6:09 ` [patch 04/13] param_sysfs_builtin memchr argument fix Greg KH
2007-11-15 16:11 ` Chuck Ebbert
2007-11-15 17:58 ` Greg KH
2007-11-15 20:46 ` Chuck Ebbert
2007-11-15 21:20 ` Jan Kiszka
2007-11-15 23:58 ` Greg KH
2007-11-15 6:09 ` [patch 05/13] HOWTO: update ja_JP/HOWTO with latest changes Greg KH
2007-11-15 6:09 ` [patch 06/13] SLUB: Fix memory leak by not reusing cpu_slab Greg KH
2007-11-15 6:09 ` [patch 07/13] writeback: dont propagate AOP_WRITEPAGE_ACTIVATE Greg KH
2007-11-15 6:09 ` [patch 08/13] splice: fix double kunmap() in vmsplice copy path Greg KH
2007-11-15 6:09 ` [patch 09/13] fix the softlockup watchdog to actually work Greg KH
2007-11-15 6:09 ` [patch 10/13] sched: keep utime/stime monotonic Greg KH
2007-11-15 6:09 ` [patch 11/13] Fix compat futex hangs Greg KH
2007-11-15 6:09 ` [patch 12/13] fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE Greg KH
2007-11-15 6:09 ` [patch 13/13] BLOCK: Fix bad sharing of tag busy list on queues with shared tag maps Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.