Let's do it? diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c index 941041f..914e579 100644 --- a/fs/nfsd/nfssvc.c +++ b/fs/nfsd/nfssvc.c @@ -36,12 +36,7 @@ #define NFSDDBG_FACILITY NFSDDBG_SVC -/* these signals will be delivered to an nfsd thread - * when handling a request - */ -#define ALLOWED_SIGS (sigmask(SIGKILL)) -/* these signals will be delivered to an nfsd thread - * when not handling a request. i.e. when waiting +/* These signals can be used to shutdown an nfsd thread. ...

Btw, I don't actually understand why interrupt "simply lost", IMO it should not.. :-/ But this what I'm observing via bunch of printks in the code flow. Maybe there is not so obvious race, which I can't see. So, help needed. Either it is a proper fix, or it is a workaround for another bug somewhere else. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

8250's initialization routines relies on the fact that _irqsave spinlock will disable local hardirqs, so that the driver can issue IRQ-triggering operations before registering the port in the IRQ chain. With RT kernels and preemptable hardirqs this isn't true, _irqsave spinlock does not disable local hardirqs, and this causes following trace: $ cat /dev/ttyS1 irq 42: nobody cared (try booting with the "irqpoll" option) Call Trace: [C0475EB0] [C0008A98] show_stack+0x4c/0x1ac (unreliable) [C0475...

As -rc1 had a number of issues, here's the set of patches for -rc2. Responses should be made by Tuesday, June 24, 18:00:00 UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.9-rc2.gz and the diffstat can be found below. thanks, greg k-h Makefile | 2 arch/powerpc/kernel/vdso.c | 2 arch/x86/kernel/setup_32.c | 10 ++ drivers/hwmo...

2.6.25.9-stable review patch. If anyone has any objections, please let us know. ------------------ From: Bernhard Walle <bwalle@suse.de> commit d3942cff620bea073fc4e3c8ed878eb1e84615ce upstream This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for i386 and prints a error message on failure. The patch is still for 2.6.26 since it is only bug fixing. The unification of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27. Signed-off-by: Bernha...

2.6.25.9-stable review patch. If anyone has any objections, please let us know. ------------------ From: Linus Torvalds <torvalds@linux-foundation.org> commit 89f5b7da2a6bad2e84670422ab8192382a5aeb9f upstream KAMEZAWA Hiroyuki and Oleg Nesterov point out that since the commit 557ed1fa2620dc119adb86b34c614e152a629a80 ("remove ZERO_PAGE") removed the ZERO_PAGE from the VM mappings, any users of get_user_pages() will generally now populate the VM with real empty pages needlessly. We us...

2.6.25.9-stable review patch. If anyone has any objections, please let us know. ------------------ From: Linus Torvalds <torvalds@linux-foundation.org> commit 1f6ef2342972dc7fd623f360f84006e2304eb935 upstream The inline assembly in drivers/watchdog/hpwdt.c was incredibly broken, and included all the function prologue and epilogue stuff, even though it was itself then inside a C function where the compiler would add its own prologue and epilogue on top of it all. This then just _happ...

2.6.25.9-stable review patch. If anyone has any objections, please let us know. ------------------ From: Jeremy Fitzhardinge <jeremy@goop.org> commit ad524d46f36bbc32033bb72ba42958f12bf49b06 upstream When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can potentially have the same number of physical address bits as the 64-bit host ("Enhanced Legacy PAE Paging"). This means, in theory, we could have up to 52 bits of physical address in a pte. The 32-bit kernel uses a 32-bit u...

Looks ok to me. Linus --

2.6.25.9-stable review patch. If anyone has any objections, please let us know. ------------------ From: Jean Delvare <khali@linux-fr.org> Function RANGE_TO_REG() is broken. For a requested range of 2000 (2 degrees C), it will return an index value of 15, i.e. 80.0 degrees C, instead of the expected index value of 0. All other values are handled properly, just 2000 isn't. The bug was introduced back in November 2004 by this patch: [ message continues ]

Inspired by Peter Zijlstra. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- kernel/sched.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/kernel/sched.c b/kernel/sched.c index 3efbbc5..c8e8520 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -2775,6 +2775,10 @@ static int move_tasks(struct rq *this_rq, int this_cpu, struct rq *busiest, max_load_move - total_load_moved, sd, idle, all_pinned, &this_best_prio); class = class->...

We do find_busiest_groups() et. al. without locks held for normal balancing, so lets do it for newidle as well. It will allow other cpus to make forward progress (against our RQ) while we try to balance and allow some interrupts to occur. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- kernel/sched.c | 44 ++++++++++++++++++++++++++++++++++++++------ 1 files changed, 38 insertions(+), 6 deletions(-) diff --git a/kernel/sched.c b/kernel/sched.c index 31f91d9..490e6bc 100644...

Hi, Today I was rebuilding software RAID arrays on one of my boxes and I did # mdadm /dev/md4 --fail /dev/sdb7 --remove /dev/sdb7 and then I thought it was a bad idea and did # mdadm /dev/md4 --add /dev/sdb7 That resulted in the following lockdep report, although the operation seemed to have completed successfully otherwise: raid1: Disk failure on sdb7, disabling device. raid1: Operation continuing on 1 devices. RAID1 conf printout: --- wd:1 rd:2 disk 0, wo:1, o:0, dev:sdb7 disk 1...

You people working hard to fix bugs and implement great filesystems ^^^ Here I get (on x86 gcc 4.3.1): fs/ext3/ialloc.c: In function 'ext3_orphan_get': fs/ext3/ialloc.c:701: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'unsigned int' So it probably should be %u or something. Sami --

[sorry for the broken USB list address in the original post.] -- Rafael J. Wysocki, Ph.D. Institute of Theoretical Physics Faculty of Physics of Warsaw University ul. Hoza 69, 00-681 Warsaw [tel: +48 22 55 32 263] [mob: +48 60 50 53 693] ---------------------------- One should not increase, beyond what is necessary, the number of entities required to explain anything. -- William of Ockham --

Huh. Does SCSI core not do a get_device() before actually scanning? It looks to me like the disconnect path did it's scsi_host_put and the host (and struct us_data) got freed immediately. Matt auth_rpcgss sunrpc exportfs iptable_filter ip_tables ip6table_filter ip6_t= ables x_tables ipv6 cpufreq_conservative cpufreq_ondemand cpufreq_userspace= cpufreq_powersave powernow_k8 freq_table snd_pcm_oss snd_mixer_oss snd_seq= snd_seq_device reiserfs dm_mod ohci1394 sr_mod cdrom floppy ieee1394 serio...

From: Julia Lawall <julia@diku.dk> Taking sizeof the result of sizeof is quite strange and does not seem to be what is wanted here. This was fixed using the following semantic patch. (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression E; @@ - sizeof ( sizeof (E) - ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- diff -u -p a/drivers/net/r6040.c b/drivers/net/r6040.c --- a/drivers/net/r6040.c 2008-06-17 19:46:52.000000000 +0200 +++...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/srat_32.c | 31 +++++++++++++++++++------------ arch/x86/mm/discontig_32.c | 29 +++++++++++++++-------------- 2 files changed, 34 insertions(+), 26 deletions(-) Index: linux-2.6/arch/x86/kernel/srat_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/srat_32.c +++ linux-2.6/arch/x86/kernel/srat_32.c @@ -93,7 +93,7 @@ acpi_numa_processor_affinity_init(struc...

Linus, please pull the latest core kernel fixes git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core-fixes-for-linus Ingo ------------------> Thomas Gleixner (1): futexes: fix fault handling in futex_lock_pi kernel/futex.c | 93 ++++++++++++++++++++++++++++++++++++++++++++------------ 1 files changed, 73 insertions(+), 20 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index 449def8..7d1136e 100644 --- a/kernel/futex.c +++ ...

Linus, please pull the latest x86 fixes tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus NOTE: contains the second, lguest half of the FPU fixlet from Suresh. Ingo ------------------> Isaku Yamahata (1): xen: Use wmb instead of rmb in xen_evtchn_do_upcall(). Jeremy Fitzhardinge (2): xen: mask unwanted pte bits in __supported_pte_mask xen: don't drop NX bit Suresh Siddha (1): x86: fix NULL pointer deref...

So how many 'FFS' filesystems does that make now? Why not ForenFS or something more unique? -- Len Sorensen --

Linus, please pull from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This tree is also available from kernel.org mirrors at: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This will get a fix for one rare bug seen by SGI on large clusters: Eli Cohen (1): IB/mthca: Clear ICM pages before handing to FW drivers/infiniband/hw/mthca/mthca_memfree.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) di...

On Mon, Jun 23, 2008 at 2:17 PM, Daniel J Blueman Testing is hard as the oops is not easily reproducible, but I'll prepare a non-4KSTACKS kernel so that I can boot to it if we oops again. I'm still interested to hear from someone if the patch in bugzilla is good for catching a real error case, or if it's papering over a larger problem (for example a stack overrun). Ian --

OK, I've applied everything except the last one (all in for-linus in vfs-2.6.git). As for the stuff outside current->root (or other namespace, for that matter)... I don't like the idea of using // - as it is, we have a nice sane check (path[0] != '/') and if anything, I'd consider going for deleted:<path> instead of <path> (deleted) as we have now. _That_ would eliminate the major annoyance with handling of unlinked/rmdired - we'd get rid of guessing whether that's a file really cal...

unreachable: ? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --