Here is a simple patch to use an allocated array of cpumasks to represent cpumask_of_cpu() instead of constructing one on the stack. It's based on the Kconfig option "HAVE_CPUMASK_OF_CPU_MAP" which is currently only set for x86_64 SMP. Note that the existing cpumask_of_cpu() macro is also changed to produce an lvalue so a pointer to it can be used. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git ...

Some more small changes for x86 in preparation of larger cpumask changes. * Introduce the cpumask_of_cpu_map via Kconfig option * Modify show_shared_cpu_map in intel_cacheinfo.c to use cpulist_scnprintf() instead of cpumask_scnprintf(). This eliminates the need for the new function cpumask_scnprintf_len(). Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Signed-off-by: M...

Linus, Olof Johansson has a defconfig update for the pasemi platform that he would like to have in 2.6.25, so please do: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge Thanks, Paul. arch/powerpc/configs/pasemi_defconfig | 142 ++++++++++++++++++++------------- 1 files changed, 88 insertions(+), 54 deletions(-) commit 5c29934de29ddd7ecd913d83cad28e872f2e8c78 Author: Olof Johansson <olof@lixom.net> Date: Tue Mar 25 10:28:26 2008 -0500 [P...

So I think this has a nicer calling convention, but you never answered the question about what the *point* of this all is. This is _still_ uglier than what we already have, which is to just have the code call "[compat_]ptrace_request()" for any cases they don't recognize. I wanted to know if there was some actual technical point to it, and never got a reply to that. Linus --

Booted up with an ancient bt848 card present and got this.. BUG: unable to handle kernel NULL pointer dereference at 000001e0 IP: [<c0500ba2>] strlen+0xb/0x15 *pde = 02e0d067 *pte = 00000000 Oops: 0000 [#1] SMP Modules linked in: sha256_generic aes_generic cbc dm_crypt crypto_blkcipher dm_emc dm_round_robin dm_multipath dm_snapshot dm_mirror dm_zero dm_mod xfs jfs reiserfs lock_nolock gfs2 msdos linear raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 sg sr_mod cdrom sd_mod ata...

This message contains a list of some regressions from 2.6.24 reported since 2.6.25-rc1 was released, for which there are no fixes in the mainline I know of.  If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.24, please let me know either and I'll add them to the list.  Also, please let me know if any of the entries below are invalid. Listed regressions statistics: Date Total Pending Unresolved ---------------...

drivers/scsi/aic7xxx_old/sequencer.h:130:#define AIC_OP_JZ 0xf -- Test opcode, not definition Signed-off-by: Roel Kluin <12o3l@tiscali.nl> --- diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y index 6066998..702e2db 100644 --- a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y +++ b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y @@ -1837,7 +1837,7 @@ type_check(symbol_t *symbol, expression_t *expression, int opcode) int and_op; and_op = FALSE; ...

This fixes a regresssion in 2.6.25 ... presumably it's a better fix than the hack I came up with. I think this regression should be fixed before 2.6.25-final freezes.

What CPU/chipset is this? Rafael --

Ingo, this patch makes no sense. Two reasons: - "error_code & 16" is senseless. Use PF_INSTR instead, which actually tells the reader something. - this piece of crap code is immediately followed by /* If it was a exec fault on NX page, ignore */ if (error_code & PF_INSTR) return 0; which uses that *right* and readable PF_INSTR #define, and also shows that the newly modified code is totally insane (ie: if the new code triggers, then it would have returne...

scratch that 24 hours - the patch is obviously correct as it only removes the nonsensical bits that get duplicated below anyway. Linus, please pull the latest x86 git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git for-linus Thanks, Ingo ------------------> Ingo Molnar (1): x86: prefetch fix #2 arch/x86/mm/fault.c | 11 ++++------- 1 files changed, 4 insertions(+), 7 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault...

heh, did the exact same cleanup :) i suspect we would be fine with a simple: if (error_code & PF_INSTR) return 0; because if we get a fault on an instruction fetch then it clearly cannot be a prefetch erratum ... The NX condition simply comes from a cautious 32-bit workaround. (on 64-bit we always have NX - at least on AMD which has this erratum.) and thus the currently pulled code is not incorrect, just ugly and nonsensical. Ingo --

How about: If it was an exec (instruction fetch) fault, it cannot be a prefetch Cheers, Harvey --

Hi Peter, Ingo could you spend a few minutes on me? ;) You know, I'm almost complete changing the vm86 flags with X86_EFLAGS_... but there is a hidden problem lays. Look, in vm86.h we have the definition #ifdef CONFIG_VM86 #define VM_MASK 0x00020000 #else #define VM_MASK 0 /* ignored */ #endif which has an indirect conditional compilation effect. For example, if we take a look on include/asm-x86/ptrace.h static inline int v8086_mode(struct pt_regs *regs) { #ifdef CONFIG_X86_32 ...

Thanks a lot, Peter - Cyrill - --

From: Milan Broz <mbroz@redhat.com> Fix regression in dm-crypt introduced in commit 3a7f6c990ad04e6f576a159876c602d14d6f7fef (dm crypt: use async crypto). If write requests need to be split into pieces, the code must not process them in parallel because the crypto context cannot be shared. So there can be parallel crypto operations on one part of the write, but only one write bio can be processed at a time. This is not optimal and the workqueue code needs to be optimized for parallel pr...

Give it another try, an admin tried (and then reverted) a quick experiment. Sorry! Jeff --

Yeah, it's driver core rework, the kobject stuff was the first step to try to get there... It's slow going unfortunatly other things more pressing keep popping up ahead of it, it's getting there... No objection to this patch at all: Acked-by: Greg Kroah-Hartman <gregkh@suse.de> thanks, greg k-h --

This looks somehow fishy (note the "rc" settings): <-- snip --> ... int cifs_mount(struct super_block *sb, struct cifs_sb_info *cifs_sb, char *mount_data, const char *devname) { ... /* BB check if this works for exactly length * three strings */ if ((strchr(volume_info.UNC + 3, '\\') == NULL) && (strchr(volume_info.UNC + 3, '/') == ...

Hi, here's the last series I was owing. After that, smp_32.h and smp_64.h are gone, merged into smp.h as usual, compiled tested in ~ 8 randconfigs for each architecture, and boot tested in all my hardware. enjoy full diffstat: a/include/asm-x86/smp_32.h | 12 ----- a/include/asm-x86/smp_64.h | 12 ----- b/arch/x86/xen/smp.c | 7 +-- b/include/asm-x86/smp.h | 27 ++++++++++++ b/include/asm-x86/smp_32.h | 27 ------------ b/include/asm-x86/smp_64.h | 7 ++- inc...

Although those constants are always defined in x86_64, and will have the effect of just including the headers in the very way we did before, I'm doing this in a separate patch to be conservative and avoid surprises. Signed-off-by: Glauber Costa <gcosta@redhat.com> --- include/asm-x86/smp_64.h | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/include/asm-x86/smp_64.h b/include/asm-x86/smp_64.h index 015d36e..b83151d 100644 --- a/include/asm-x86/smp_64.h ++...

The code is now the same between i386 and x86_64. We already know what happens when it reaches this point: They go away from the arch-specific headers, and suddenly appears in the common header. Signed-off-by: Glauber Costa <gcosta@redhat.com> --- include/asm-x86/smp.h | 27 +++++++++++++++++++++++++++ include/asm-x86/smp_32.h | 27 --------------------------- include/asm-x86/smp_64.h | 27 --------------------------- 3 files changed, 27 insertions(+), 54 deletions(-) diff --gi...

APIC_DEFINITION is not defined in x86_64, so in practice, we keep our old code here. But as a nice side effect, the code is now equal to smp_32.h. Signed-off-by: Glauber Costa <gcosta@redhat.com> --- include/asm-x86/smp_64.h | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/smp_64.h b/include/asm-x86/smp_64.h index c53a011..2520633 100644 --- a/include/asm-x86/smp_64.h +++ b/include/asm-x86/smp_64.h @@ -52,12 +52,16 @@ static inline int logica...

xen does not use the global cpu_initialized mask, but rather, a specific one. So we change its name so it won't conflict with the upcoming movement of cpu_initialized_mask from smp_64.h to smp_32.h. Signed-off-by: Glauber Costa <gcosta@redhat.com> CC: Jeremy Fitzhardinge <jeremy@goop.org> --- arch/x86/xen/smp.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 6b3c37b..92dd3db 100644 --- a/arch/x86/xen/smp.c ...

I wrote a new wiki page that assists users in understanding the goop that libata spits out into your dmesg: http://ata.wiki.kernel.org/index.php/Libata_error_messages Jeff --