login
Search
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(-)
-
-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...
-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 filesyste...
-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 #1I 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/...
-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 monotoniccommit 9301899be75b464ef097f0b5af7af6d9bd8f68a7
Author: Balbir Singh <balbir@linux.vnet.ibm.com>
sched: fix /proc/<PID>/stat stime/utime monotonicity, part 2Signed-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 count...
-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. processSigned-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 nc...
-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 -0700Ignore 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)) {--
-
-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/0x8eSigned-off-by: Jens Axboe &l...
-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;--
-
-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)) {--
-
-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_...
-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
[...
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
-
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
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
-
-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...
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_structsize = (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-&g...
| Mark Lord | 2.6.25-rc8: FTP transfer errors |
| Kamalesh Babulal | Re: 2.6.23-rc6-mm1 |
| Greg Kroah-Hartman | [PATCH 025/196] paride: Convert from class_device to device for block/paride |
| Stephen Rothwell | Announce: Linux-next (Or Andrew's dream :-)) |
git: | |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
| David Miller | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
