Re: utrace regressions (was: -mm merge plans for 2.6.21)
> On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: > > > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] > > > and [5] is also needed. > > > > It's not. The utrace_regset for the debugregs already has that behavior > > for those two words, so mapping all 8 uarea words to the regset is fine. > > Sorry, I don't get it. Choosing segment from x86_64_uarea is done before > calling regset->set and regset->get as well as before zero-filling. No > segment for u_debugreg[4] and [5] means -EIO before segment handlers > will have a chance to be called. > > Do you want to consolidate these two? > > {offsetof(struct user, u_debugreg[0]), offsetof(struct user, > u_debugreg[4]), 3, 0}, > {offsetof(struct user, u_debugreg[6]), offsetof(struct user, > u_debugreg[8]), 3, 6 * sizeof(long)}, Oops! I was misremembering what was in x86_64_uarea when I wrote that. I've indeed fixed it to match what I thought it was: {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[8]), 3, 0}, Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to the regset is fine. Sorry, I don't get it. Choosing segment from x86_64_uarea is done before calling regset-set and regset-get as well as before zero-filling. No segment for u_debugreg[4] and [5] means -EIO before segment handlers will have a chance to be called. Do you want to consolidate these two? {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[4]), 3, 0}, {offsetof(struct user, u_debugreg[6]), offsetof(struct user, u_debugreg[8]), 3, 6 * sizeof(long)}, Oops! I was misremembering what was in x86_64_uarea when I wrote that. I've indeed fixed it to match what I thought it was: {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[8]), 3, 0}, Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: > > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] > > and [5] is also needed. > > It's not. The utrace_regset for the debugregs already has that behavior > for those two words, so mapping all 8 uarea words to the regset is fine. Sorry, I don't get it. Choosing segment from x86_64_uarea is done before calling regset->set and regset->get as well as before zero-filling. No segment for u_debugreg[4] and [5] means -EIO before segment handlers will have a chance to be called. Do you want to consolidate these two? {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[4]), 3, 0}, {offsetof(struct user, u_debugreg[6]), offsetof(struct user, u_debugreg[8]), 3, 6 * sizeof(long)}, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to the regset is fine. Sorry, I don't get it. Choosing segment from x86_64_uarea is done before calling regset-set and regset-get as well as before zero-filling. No segment for u_debugreg[4] and [5] means -EIO before segment handlers will have a chance to be called. Do you want to consolidate these two? {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[4]), 3, 0}, {offsetof(struct user, u_debugreg[6]), offsetof(struct user, u_debugreg[8]), 3, 6 * sizeof(long)}, - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
> Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] > and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to the regset is fine. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to the regset is fine. Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Tue, Feb 13, 2007 at 04:05:30PM +0300, Alexey Dobriyan wrote: > On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: > > > 2. The following proggie renders box unusable in ~10 seconds (but not > > >mainline kernel where Ctrl+C will kill process). > > > > I haven't been able to reproduce this so far on my test machine. I got > > bored after about 10 minutes ("passed: 11920"). The machine remains > > responsive and the test dies immediately on hitting C-c. I'll try it on > > some other machines. It would help to know what kind of unusable (crashy, > > leaky, wedgey?). > > This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with > linux-2.6.20-current-utrace.patch slapped on top (without rejects) > utrace is on and ptrace is on too. > > the behaviour is > > $ expl_ptratt > passed: 10 > passed: 20 > ... > passed: [always different number, but in several seconds] > [pause] > [OOM killer wakes up steadily killing processes ] > [messages scroll away ] > > I'll turn more debugging options now. > > Just in case, .config: Turning preempt off makes OOM-killings dissapear. > # CONFIG_PREEMPT_NONE is not set > CONFIG_PREEMPT_VOLUNTARY=y > # CONFIG_PREEMPT is not set > # CONFIG_X86_UP_APIC is not set - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Tue, Feb 13, 2007 at 04:05:30PM +0300, Alexey Dobriyan wrote: On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: 2. The following proggie renders box unusable in ~10 seconds (but not mainline kernel where Ctrl+C will kill process). I haven't been able to reproduce this so far on my test machine. I got bored after about 10 minutes (passed: 11920). The machine remains responsive and the test dies immediately on hitting C-c. I'll try it on some other machines. It would help to know what kind of unusable (crashy, leaky, wedgey?). This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with linux-2.6.20-current-utrace.patch slapped on top (without rejects) utrace is on and ptrace is on too. the behaviour is $ expl_ptratt passed: 10 passed: 20 ... passed: [always different number, but in several seconds] [pause] [OOM killer wakes up steadily killing processes ] [messages scroll away ] I'll turn more debugging options now. Just in case, .config: Turning preempt off makes OOM-killings dissapear. # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: > > We're aware of two regressions compared to mainline if ptrace is utrace: > > Thanks very much for bringing these to my attention. > > > 1) zero holes for PTRACE_PEEKUSR vanished. > > I've fixed this in the current patches. Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. --- a/arch/x86_64/kernel/ptrace.c +++ b/arch/x86_64/kernel/ptrace.c @@ -687,6 +687,8 @@ EXPORT_SYMBOL_GPL(utrace_x86_64_native); #ifdef CONFIG_PTRACE static const struct ptrace_layout_segment x86_64_uarea[] = { {0, sizeof(struct user_regs_struct), 0, 0}, + {sizeof(struct user_regs_struct), +offsetof(struct user, u_debugreg[0]), -1, 0}, {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[4]), 3, 0}, {offsetof(struct user, u_debugreg[6]), - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: > > 2. The following proggie renders box unusable in ~10 seconds (but not > >mainline kernel where Ctrl+C will kill process). > > I haven't been able to reproduce this so far on my test machine. I got > bored after about 10 minutes ("passed: 11920"). The machine remains > responsive and the test dies immediately on hitting C-c. I'll try it on > some other machines. It would help to know what kind of unusable (crashy, > leaky, wedgey?). This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with linux-2.6.20-current-utrace.patch slapped on top (without rejects) utrace is on and ptrace is on too. the behaviour is $ expl_ptratt passed: 10 passed: 20 ... passed: [always different number, but in several seconds] [pause] [OOM killer wakes up steadily killing processes ] [messages scroll away ] I'll turn more debugging options now. Just in case, .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Tue Feb 13 15:28:38 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: 2. The following proggie renders box unusable in ~10 seconds (but not mainline kernel where Ctrl+C will kill process). I haven't been able to reproduce this so far on my test machine. I got bored after about 10 minutes (passed: 11920). The machine remains responsive and the test dies immediately on hitting C-c. I'll try it on some other machines. It would help to know what kind of unusable (crashy, leaky, wedgey?). This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with linux-2.6.20-current-utrace.patch slapped on top (without rejects) utrace is on and ptrace is on too. the behaviour is $ expl_ptratt passed: 10 passed: 20 ... passed: [always different number, but in several seconds] [pause] [OOM killer wakes up steadily killing processes ] [messages scroll away ] I'll turn more debugging options now. Just in case, .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Tue Feb 13 15:28:38 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD
Re: utrace regressions (was: -mm merge plans for 2.6.21)
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: We're aware of two regressions compared to mainline if ptrace is utrace: Thanks very much for bringing these to my attention. 1) zero holes for PTRACE_PEEKUSR vanished. I've fixed this in the current patches. Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. --- a/arch/x86_64/kernel/ptrace.c +++ b/arch/x86_64/kernel/ptrace.c @@ -687,6 +687,8 @@ EXPORT_SYMBOL_GPL(utrace_x86_64_native); #ifdef CONFIG_PTRACE static const struct ptrace_layout_segment x86_64_uarea[] = { {0, sizeof(struct user_regs_struct), 0, 0}, + {sizeof(struct user_regs_struct), +offsetof(struct user, u_debugreg[0]), -1, 0}, {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[4]), 3, 0}, {offsetof(struct user, u_debugreg[6]), - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > > As to the size of the MCE code doing everything EDAC K8 does, that > is > > mostly true. BUT then the x86_64 MCE mechanism becomes the > exception > > path. > > Sorry you lost me on that one. > > -Andi In similiar manner of the original SATA driver model, the one that didn't use the SCSI stack. Then the SATA model was enhanced to fit under SCSI, then the SATA drivers ported to run under the SATA module. At that point, the original SATA driver model was an exception to the SATA model. Yes, if all the world used the hardware MCE mechanism, then the MCE device probably would satisify the requirements. But since linux runs across so many architectures and processors, the export of a single architecture's mechanism then implies that a second interface is necessary anyway in order to provide for those "other" archs. At that point we then move the abstraction into userspace anyway. Scripts will then need to "know" which arch they are on, in order to pull ECC events from one or the other interface. Thus, where is the line as to where the "portable" abstraction "fits"? thanks for your comments doug t - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
> I am currently developing enhancements to EDAC that provide for L1, L2, > etc cache ECC event harvesting, mce.c + mcelog do that already for all x86-64 cpus because that's all reported as standard x86 machine checks. > DMA ECC event harvest, interconnect > harvesting, and other chipset/processing ECC event harvesting. Some > events are polled others are software interupt delivered. This is on an > arch OTHER than x86 or x86_64. But these EDAC features can be used on > the x86/x86_64 as well. Well at least the CPU features are redundant. > As there IS an ECC event consumption race between MCE and EDAC, then at > least a 'config' mechanism can be utilized to switch between the two. Possibly, but it's still unclear why you want another interface if an already existing one is there and works. Anyways if you feel strongly about having redundant interfaces you could probably do it. For the CPU caches etc. it shouldn't make much difference, although it is unlikely to be very useful either. But as I wrote earlier EDAC could be made a consumer of mce.c events and munge them in whatever format you like there. Basically it could be an additional presentation layer for Alan's enterprise users with the hardware schematics at hand. My main objection to the K8 northbridge control was though that it was done in a somewhat non practical way in EDAC (no useful decoding) and it actually steals the events from the subsystem that does the useful decoding. > Better yet, Beauty in the eye of the beholder i guess @) > I would like to be able to capture the MCE events and > funnel them to EDAC, when loaded, as a downstream consumer of the MCE > event stream. Then EDAC would process the information and then proceed > to inform whether the event was handled or not by EDAC. Additionally, > it would inform whether a panic should occur or not. Yes, just mce.c has all that logic already. Not sure what adding another layer would help there. [In fact it has too much logic already, more powerful than current x86 CPUs can support] Or do you want that to be decided by user space code? That would seem somewhat risky to me. > When EDAC is not loaded, then MCE would act as it does now. > > The downside with both EDAC and MCE being in place, is that there would > be ONE MCE processing pattern for the AMD x86_64 processors No, mce.c handles all the machine checks on Intel CPUs just fine too. The thing it doesn't do is process chipset events. I can see the value of external drivers here, although that should be hopefully a temporary state until Intel finally has integrated memory controllers too. Ok PCI error reporting will be likely always separate, but I'm not sure that it fits very well because it should rather feed directly into the drivers for them to report IO errors up the normal stacks. > and the > EDAC pattern for all the other archs/processors. As far as I can tell, > other MCE processors don't generate the events as advertized. Maybe I > am wrong on that, but I can't find them. How much hardware specific > detail should be exported? All MCE capable processors generate events, although how many of them are recoverable greatly varies (often you just get a unrecoverable exception) > > I assert the better solution is to have the ability to hook into the > MCE event stream by the EDAC K8 driver, then provide action rules (EDAC > controls) The latest (pre released) mcelog 0.8pre has triggers for excessive memory errors per DIMM. Is that something you want to do for EDAC too? > As to the size of the MCE code doing everything EDAC K8 does, that is > mostly true. BUT then the x86_64 MCE mechanism becomes the exception > path. Sorry you lost me on that one. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
> We're aware of two regressions compared to mainline if ptrace is utrace: Thanks very much for bringing these to my attention. > 1) zero holes for PTRACE_PEEKUSR vanished. I've fixed this in the current patches. > 2. The following proggie renders box unusable in ~10 seconds (but not >mainline kernel where Ctrl+C will kill process). I haven't been able to reproduce this so far on my test machine. I got bored after about 10 minutes ("passed: 11920"). The machine remains responsive and the test dies immediately on hitting C-c. I'll try it on some other machines. It would help to know what kind of unusable (crashy, leaky, wedgey?). Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 11:04:48AM -0600, Robert Hancock wrote: > Frederik Deweerdt wrote: > >>How about this one instead then: > >Well, the warning you get is not that obvious: > >test.c: In function 'main': > >test.c:11: warning: 'deprecated_irqf' is deprecated > >And as far as I could test ... which apparently was not enough :) > >(gcc 4.1.1 and gcc 3.4.3), Arjan's comment is > >not true, the "static const int" don't use extra space, they get > >optimized away by the compiler (see http://lkml.org/lkml/2007/2/9/106). > > gcc 3.2 should be tested as well, that is still supported by the kernel, and > versions before 3.4 did not have unit-at-a-time optimizations. Sorry for the delay. I've setup a 3.2.3 gcc and, indeed, the symbols make their way in the binary... $ gcc-3.2.3 -O2 -c dont_use_flag.c $ nm dont_use_flag.o r SA_INTERRUPT T main U printf Regards, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > Alan <[EMAIL PROTECTED]> writes: > > > Please just push the EDAC K8 stuff. Andi will say "no" from now > until the > > end of time, but end users want it, distributions want it, and Andi > is > > not the EDAC maintainer so should consider himself overruled on > what > > isn't a technical issue but a personal political viewpoint. > > Well it's a technical issue -- it conflicts with the machine check > code that is already implemented by stealing away its events. > You would first need a CONFIG_MCE=n on x86-64 at least, otherwise > one of them will be unhappy. > > The other issue is that the existing code does everything EDAC > K8 does already perfectly fine, just in a small fraction of > the code. > > -Andi I assert that there is a greater than just a technical implementation issue. I maintain that it is a design pattern issue. The MCE hardware mechanism is a good mechanism for reporting Hardware events. The problem comes in as to WHERE those events should be handled. EDAC was designed to be a 'stack' of drivers. The upper CORE module is to provide an abstraction, whose presentation to user space is to be uniform across processes and architectures. The individual lower drivers, which register with the core, handle the machine and/or architecture specifics of 'driving' the hardware and funnel events to the core. EDAC is operational now on MIPS and ARM architectures (phone device) as well as on x86 and x86_64. Additional features of a given arch/processor that can be utilized in harvesting hardware events should be captured and then funneled to the 'low' level EDAC driver. That driver can then pass the event onto the CORE module for further processings and presentation, as determined by the controls into the CORE. MCE event processing should be funneled to the EDAC K8 driver and not directly to userspace. The design pattern I have been trying to utilize in EDAC, is the same one used by the Network stack and the SCSI stack. If I have a new NIC, which has some great new hardware feature, should the driver export that feature outside of the network stack, which does not CURRENTLY support the processing of the feature. OR should the network stack control paths be extended to provide a mechanism whereby that new feature could be utilized? Similiar design pattern exists on the SCSI stack, with device features and hardware abilities. I am currently developing enhancements to EDAC that provide for L1, L2, etc cache ECC event harvesting, DMA ECC event harvest, interconnect harvesting, and other chipset/processing ECC event harvesting. Some events are polled others are software interupt delivered. This is on an arch OTHER than x86 or x86_64. But these EDAC features can be used on the x86/x86_64 as well. As there IS an ECC event consumption race between MCE and EDAC, then at least a 'config' mechanism can be utilized to switch between the two. Better yet, I would like to be able to capture the MCE events and funnel them to EDAC, when loaded, as a downstream consumer of the MCE event stream. Then EDAC would process the information and then proceed to inform whether the event was handled or not by EDAC. Additionally, it would inform whether a panic should occur or not. When EDAC is not loaded, then MCE would act as it does now. The downside with both EDAC and MCE being in place, is that there would be ONE MCE processing pattern for the AMD x86_64 processors and the EDAC pattern for all the other archs/processors. As far as I can tell, other MCE processors don't generate the events as advertized. Maybe I am wrong on that, but I can't find them. How much hardware specific detail should be exported? I assert the better solution is to have the ability to hook into the MCE event stream by the EDAC K8 driver, then provide action rules (EDAC controls) in processing those events, which EDAC would return to the MCE stream. As to the size of the MCE code doing everything EDAC K8 does, that is mostly true. BUT then the x86_64 MCE mechanism becomes the exception path. Even the company using EDAC on the phone device doesn't mind the 60 kilobytes. doug t - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH x86 for review III] [24/29] x86_64: -mm merge plans for 2.6.21
From: Ralf Baechle <[EMAIL PROTECTED]> On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Ralf Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/ia32/ia32entry.S |1 + 1 file changed, 1 insertion(+) Index: linux/arch/x86_64/ia32/ia32entry.S === --- linux.orig/arch/x86_64/ia32/ia32entry.S +++ linux/arch/x86_64/ia32/ia32entry.S @@ -730,4 +730,5 @@ ia32_sys_call_table: .quad compat_sys_vmsplice .quad compat_sys_move_pages .quad sys_getcpu + .quad sys_epoll_pwait ia32_syscall_end: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
utrace regressions (was: -mm merge plans for 2.6.21)
> utrace-utrace-tracehook.patch > utrace-utrace-tracehook-ia64.patch > utrace-utrace-tracehook-sparc64.patch > utrace-utrace-tracehook-s390.patch > utrace-utrace-regset.patch > utrace-utrace-regset-ia64.patch > utrace-utrace-regset-sparc64.patch > utrace-utrace-regset-s390.patch > utrace-utrace-core.patch > utrace-utrace-ptrace-compat.patch > utrace-utrace-ptrace-compat-ia64.patch > utrace-utrace-ptrace-compat-sparc64.patch > utrace-utrace-ptrace-compat-s390.patch > utrace just got added to -mm. We're aware of two regressions compared to mainline if ptrace is utrace: 1) zero holes for PTRACE_PEEKUSR vanished. strace(1) when sees unknown syscall, does something like: for (i = 0; i < MAX_ARGS; i++) if (ptrace(PTRACE_PEEKUSR, i * 4, ...) < 0) return -1; since THREAD_SIZE is 17 on x86 which is less that MAX_ARGS (32 on x86), you'll get -EIO(utrace) or 0(ptrace) when i=0. No new syscalls stracing for developers. Proposed patch: --- a/arch/i386/kernel/ptrace.c +++ b/arch/i386/kernel/ptrace.c @@ -728,6 +728,7 @@ EXPORT_SYMBOL_GPL(utrace_i386_native); #ifdef CONFIG_PTRACE static const struct ptrace_layout_segment i386_uarea[] = { {0, FRAME_SIZE*4, 0, 0}, + {FRAME_SIZE*4, offsetof(struct user, u_debugreg[0]), -1, 0}, {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[8]), 4, 0}, {0, 0, -1, 0} Looks like x86_64 also needs zero holes added, haven't checked in runtime. --- 2. The following proggie renders box unusable in ~10 seconds (but not mainline kernel where Ctrl+C will kill process). #include #include #include #include #include static void *thread_func(void *arg) { execl("/proc/self/exe", NULL); return NULL; } int main(int argc, const char *argv[]) { pthread_t thread; int pid, n; if (argv[0] && (pid = fork())) for (n = 1; /*n < 100*/; ++n) { ptrace(PTRACE_ATTACH, pid, NULL, 0); ptrace(PTRACE_DETACH, pid, NULL, 0); if (!(n % 10)) printf("passed: %d\n", n); } if (pthread_create(, NULL, thread_func, NULL)) perror("pthread_create"); while (1) pause(); return 1; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
utrace regressions (was: -mm merge plans for 2.6.21)
utrace-utrace-tracehook.patch utrace-utrace-tracehook-ia64.patch utrace-utrace-tracehook-sparc64.patch utrace-utrace-tracehook-s390.patch utrace-utrace-regset.patch utrace-utrace-regset-ia64.patch utrace-utrace-regset-sparc64.patch utrace-utrace-regset-s390.patch utrace-utrace-core.patch utrace-utrace-ptrace-compat.patch utrace-utrace-ptrace-compat-ia64.patch utrace-utrace-ptrace-compat-sparc64.patch utrace-utrace-ptrace-compat-s390.patch utrace just got added to -mm. We're aware of two regressions compared to mainline if ptrace is utrace: 1) zero holes for PTRACE_PEEKUSR vanished. strace(1) when sees unknown syscall, does something like: for (i = 0; i MAX_ARGS; i++) if (ptrace(PTRACE_PEEKUSR, i * 4, ...) 0) return -1; since THREAD_SIZE is 17 on x86 which is less that MAX_ARGS (32 on x86), you'll get -EIO(utrace) or 0(ptrace) when i=0. No new syscalls stracing for developers. Proposed patch: --- a/arch/i386/kernel/ptrace.c +++ b/arch/i386/kernel/ptrace.c @@ -728,6 +728,7 @@ EXPORT_SYMBOL_GPL(utrace_i386_native); #ifdef CONFIG_PTRACE static const struct ptrace_layout_segment i386_uarea[] = { {0, FRAME_SIZE*4, 0, 0}, + {FRAME_SIZE*4, offsetof(struct user, u_debugreg[0]), -1, 0}, {offsetof(struct user, u_debugreg[0]), offsetof(struct user, u_debugreg[8]), 4, 0}, {0, 0, -1, 0} Looks like x86_64 also needs zero holes added, haven't checked in runtime. --- 2. The following proggie renders box unusable in ~10 seconds (but not mainline kernel where Ctrl+C will kill process). #include stdio.h #include unistd.h #include pthread.h #include sys/ptrace.h #include signal.h static void *thread_func(void *arg) { execl(/proc/self/exe, NULL); return NULL; } int main(int argc, const char *argv[]) { pthread_t thread; int pid, n; if (argv[0] (pid = fork())) for (n = 1; /*n 100*/; ++n) { ptrace(PTRACE_ATTACH, pid, NULL, 0); ptrace(PTRACE_DETACH, pid, NULL, 0); if (!(n % 10)) printf(passed: %d\n, n); } if (pthread_create(thread, NULL, thread_func, NULL)) perror(pthread_create); while (1) pause(); return 1; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH x86 for review III] [24/29] x86_64: -mm merge plans for 2.6.21
From: Ralf Baechle [EMAIL PROTECTED] On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Ralf Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Signed-off-by: Andi Kleen [EMAIL PROTECTED] --- arch/x86_64/ia32/ia32entry.S |1 + 1 file changed, 1 insertion(+) Index: linux/arch/x86_64/ia32/ia32entry.S === --- linux.orig/arch/x86_64/ia32/ia32entry.S +++ linux/arch/x86_64/ia32/ia32entry.S @@ -730,4 +730,5 @@ ia32_sys_call_table: .quad compat_sys_vmsplice .quad compat_sys_move_pages .quad sys_getcpu + .quad sys_epoll_pwait ia32_syscall_end: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
--- Andi Kleen [EMAIL PROTECTED] wrote: Alan [EMAIL PROTECTED] writes: Please just push the EDAC K8 stuff. Andi will say no from now until the end of time, but end users want it, distributions want it, and Andi is not the EDAC maintainer so should consider himself overruled on what isn't a technical issue but a personal political viewpoint. Well it's a technical issue -- it conflicts with the machine check code that is already implemented by stealing away its events. You would first need a CONFIG_MCE=n on x86-64 at least, otherwise one of them will be unhappy. The other issue is that the existing code does everything EDAC K8 does already perfectly fine, just in a small fraction of the code. -Andi I assert that there is a greater than just a technical implementation issue. I maintain that it is a design pattern issue. The MCE hardware mechanism is a good mechanism for reporting Hardware events. The problem comes in as to WHERE those events should be handled. EDAC was designed to be a 'stack' of drivers. The upper CORE module is to provide an abstraction, whose presentation to user space is to be uniform across processes and architectures. The individual lower drivers, which register with the core, handle the machine and/or architecture specifics of 'driving' the hardware and funnel events to the core. EDAC is operational now on MIPS and ARM architectures (phone device) as well as on x86 and x86_64. Additional features of a given arch/processor that can be utilized in harvesting hardware events should be captured and then funneled to the 'low' level EDAC driver. That driver can then pass the event onto the CORE module for further processings and presentation, as determined by the controls into the CORE. MCE event processing should be funneled to the EDAC K8 driver and not directly to userspace. The design pattern I have been trying to utilize in EDAC, is the same one used by the Network stack and the SCSI stack. If I have a new NIC, which has some great new hardware feature, should the driver export that feature outside of the network stack, which does not CURRENTLY support the processing of the feature. OR should the network stack control paths be extended to provide a mechanism whereby that new feature could be utilized? Similiar design pattern exists on the SCSI stack, with device features and hardware abilities. I am currently developing enhancements to EDAC that provide for L1, L2, etc cache ECC event harvesting, DMA ECC event harvest, interconnect harvesting, and other chipset/processing ECC event harvesting. Some events are polled others are software interupt delivered. This is on an arch OTHER than x86 or x86_64. But these EDAC features can be used on the x86/x86_64 as well. As there IS an ECC event consumption race between MCE and EDAC, then at least a 'config' mechanism can be utilized to switch between the two. Better yet, I would like to be able to capture the MCE events and funnel them to EDAC, when loaded, as a downstream consumer of the MCE event stream. Then EDAC would process the information and then proceed to inform whether the event was handled or not by EDAC. Additionally, it would inform whether a panic should occur or not. When EDAC is not loaded, then MCE would act as it does now. The downside with both EDAC and MCE being in place, is that there would be ONE MCE processing pattern for the AMD x86_64 processors and the EDAC pattern for all the other archs/processors. As far as I can tell, other MCE processors don't generate the events as advertized. Maybe I am wrong on that, but I can't find them. How much hardware specific detail should be exported? I assert the better solution is to have the ability to hook into the MCE event stream by the EDAC K8 driver, then provide action rules (EDAC controls) in processing those events, which EDAC would return to the MCE stream. As to the size of the MCE code doing everything EDAC K8 does, that is mostly true. BUT then the x86_64 MCE mechanism becomes the exception path. Even the company using EDAC on the phone device doesn't mind the 60 kilobytes. doug t - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 11:04:48AM -0600, Robert Hancock wrote: Frederik Deweerdt wrote: How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test ... which apparently was not enough :) (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is not true, the static const int don't use extra space, they get optimized away by the compiler (see http://lkml.org/lkml/2007/2/9/106). gcc 3.2 should be tested as well, that is still supported by the kernel, and versions before 3.4 did not have unit-at-a-time optimizations. Sorry for the delay. I've setup a 3.2.3 gcc and, indeed, the symbols make their way in the binary... $ gcc-3.2.3 -O2 -c dont_use_flag.c $ nm dont_use_flag.o r SA_INTERRUPT T main U printf Regards, Frederik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
I am currently developing enhancements to EDAC that provide for L1, L2, etc cache ECC event harvesting, mce.c + mcelog do that already for all x86-64 cpus because that's all reported as standard x86 machine checks. DMA ECC event harvest, interconnect harvesting, and other chipset/processing ECC event harvesting. Some events are polled others are software interupt delivered. This is on an arch OTHER than x86 or x86_64. But these EDAC features can be used on the x86/x86_64 as well. Well at least the CPU features are redundant. As there IS an ECC event consumption race between MCE and EDAC, then at least a 'config' mechanism can be utilized to switch between the two. Possibly, but it's still unclear why you want another interface if an already existing one is there and works. Anyways if you feel strongly about having redundant interfaces you could probably do it. For the CPU caches etc. it shouldn't make much difference, although it is unlikely to be very useful either. But as I wrote earlier EDAC could be made a consumer of mce.c events and munge them in whatever format you like there. Basically it could be an additional presentation layer for Alan's enterprise users with the hardware schematics at hand. My main objection to the K8 northbridge control was though that it was done in a somewhat non practical way in EDAC (no useful decoding) and it actually steals the events from the subsystem that does the useful decoding. Better yet, Beauty in the eye of the beholder i guess @) I would like to be able to capture the MCE events and funnel them to EDAC, when loaded, as a downstream consumer of the MCE event stream. Then EDAC would process the information and then proceed to inform whether the event was handled or not by EDAC. Additionally, it would inform whether a panic should occur or not. Yes, just mce.c has all that logic already. Not sure what adding another layer would help there. [In fact it has too much logic already, more powerful than current x86 CPUs can support] Or do you want that to be decided by user space code? That would seem somewhat risky to me. When EDAC is not loaded, then MCE would act as it does now. The downside with both EDAC and MCE being in place, is that there would be ONE MCE processing pattern for the AMD x86_64 processors No, mce.c handles all the machine checks on Intel CPUs just fine too. The thing it doesn't do is process chipset events. I can see the value of external drivers here, although that should be hopefully a temporary state until Intel finally has integrated memory controllers too. Ok PCI error reporting will be likely always separate, but I'm not sure that it fits very well because it should rather feed directly into the drivers for them to report IO errors up the normal stacks. and the EDAC pattern for all the other archs/processors. As far as I can tell, other MCE processors don't generate the events as advertized. Maybe I am wrong on that, but I can't find them. How much hardware specific detail should be exported? All MCE capable processors generate events, although how many of them are recoverable greatly varies (often you just get a unrecoverable exception) I assert the better solution is to have the ability to hook into the MCE event stream by the EDAC K8 driver, then provide action rules (EDAC controls) The latest (pre released) mcelog 0.8pre has triggers for excessive memory errors per DIMM. Is that something you want to do for EDAC too? As to the size of the MCE code doing everything EDAC K8 does, that is mostly true. BUT then the x86_64 MCE mechanism becomes the exception path. Sorry you lost me on that one. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
--- Andi Kleen [EMAIL PROTECTED] wrote: As to the size of the MCE code doing everything EDAC K8 does, that is mostly true. BUT then the x86_64 MCE mechanism becomes the exception path. Sorry you lost me on that one. -Andi In similiar manner of the original SATA driver model, the one that didn't use the SCSI stack. Then the SATA model was enhanced to fit under SCSI, then the SATA drivers ported to run under the SATA module. At that point, the original SATA driver model was an exception to the SATA model. Yes, if all the world used the hardware MCE mechanism, then the MCE device probably would satisify the requirements. But since linux runs across so many architectures and processors, the export of a single architecture's mechanism then implies that a second interface is necessary anyway in order to provide for those other archs. At that point we then move the abstraction into userspace anyway. Scripts will then need to know which arch they are on, in order to pull ECC events from one or the other interface. Thus, where is the line as to where the portable abstraction fits? thanks for your comments doug t - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: utrace regressions (was: -mm merge plans for 2.6.21)
We're aware of two regressions compared to mainline if ptrace is utrace: Thanks very much for bringing these to my attention. 1) zero holes for PTRACE_PEEKUSR vanished. I've fixed this in the current patches. 2. The following proggie renders box unusable in ~10 seconds (but not mainline kernel where Ctrl+C will kill process). I haven't been able to reproduce this so far on my test machine. I got bored after about 10 minutes (passed: 11920). The machine remains responsive and the test dies immediately on hitting C-c. I'll try it on some other machines. It would help to know what kind of unusable (crashy, leaky, wedgey?). Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sun, Feb 11, 2007 at 05:14:46PM +0100, Heiko Carstens wrote: > Hmm.. so you don't need to do some fancy compat conversion for the sigset_t > that gets passed? Why is that? I don't get it... Ah, I finally get your point. Yes, that needs conversion. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sun, Feb 11, 2007 at 04:33:41PM +0100, David Woodhouse wrote: > On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: > > Unfortunately struct epoll_event contains a gap so it bets on identical > > padding rules between native and compat ABI and anyway, padding is wasted > > space so the struct members should have been swapped when this structure > > was created. Oh well, too late. > > Indeed. That was the example I was thinking of when I suggested the "no > new syscalls without _simultaneous_ compat version" rule. The need for a compat ABI is not always obvious. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sun, 11 Feb 2007, Heiko Carstens wrote: > On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: > > On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: > > > > > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > > > Which remembers me that I think that MIPS is using the non-compat > > > > version > > > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a > > > > compat > > > > syscall for some reason. Dunno. > > > > > > It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree > > > there there's 32 bits of padding between the fields of this structure: > > > > > > struct epoll_event { > > > __u32 events; > > > __u64 data; > > > }; > > > > > > I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 > > > ABI is different then it would need the compat syscall. > > > > That is correct - and apparently for all ABIs because I wasn't able to find > > a compat_sys_epoll_pwait at all. > > Hmm.. so you don't need to do some fancy compat conversion for the sigset_t > that gets passed? Why is that? I don't get it... The compat_sys_epoll_pwait function has two sources of compat. One is the sigset_t and the other one is the struct epoll_event. The sigset_t compat is always needed, while the struct epoll_event may be needed. The code of (upcoming) compat_sys_epoll_pwait takes care of both, with a smart compile-time check to wire sys_epoll_wait or compat_sys_epoll_wait, depending on the need of the struct epoll_event compat handling. So yes, compat_sys_epoll_pwait is needed. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: > On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: > > > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > > Which remembers me that I think that MIPS is using the non-compat version > > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a > > > compat > > > syscall for some reason. Dunno. > > > > It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree > > there there's 32 bits of padding between the fields of this structure: > > > > struct epoll_event { > > __u32 events; > > __u64 data; > > }; > > > > I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 > > ABI is different then it would need the compat syscall. > > That is correct - and apparently for all ABIs because I wasn't able to find > a compat_sys_epoll_pwait at all. Hmm.. so you don't need to do some fancy compat conversion for the sigset_t that gets passed? Why is that? I don't get it... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: > Unfortunately struct epoll_event contains a gap so it bets on identical > padding rules between native and compat ABI and anyway, padding is wasted > space so the struct members should have been swapped when this structure > was created. Oh well, too late. Indeed. That was the example I was thinking of when I suggested the "no new syscalls without _simultaneous_ compat version" rule. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Saturday 10 February 2007 22:05, Ralf Baechle wrote: > On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > > > Which remembers me that I think that MIPS is using the non-compat version > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > syscall for some reason. Dunno. > > Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Added thanks. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Saturday 10 February 2007 22:05, Ralf Baechle wrote: On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Added thanks. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh well, too late. Indeed. That was the example I was thinking of when I suggested the no new syscalls without _simultaneous_ compat version rule. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree there there's 32 bits of padding between the fields of this structure: struct epoll_event { __u32 events; __u64 data; }; I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 ABI is different then it would need the compat syscall. That is correct - and apparently for all ABIs because I wasn't able to find a compat_sys_epoll_pwait at all. Hmm.. so you don't need to do some fancy compat conversion for the sigset_t that gets passed? Why is that? I don't get it... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sun, 11 Feb 2007, Heiko Carstens wrote: On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree there there's 32 bits of padding between the fields of this structure: struct epoll_event { __u32 events; __u64 data; }; I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 ABI is different then it would need the compat syscall. That is correct - and apparently for all ABIs because I wasn't able to find a compat_sys_epoll_pwait at all. Hmm.. so you don't need to do some fancy compat conversion for the sigset_t that gets passed? Why is that? I don't get it... The compat_sys_epoll_pwait function has two sources of compat. One is the sigset_t and the other one is the struct epoll_event. The sigset_t compat is always needed, while the struct epoll_event may be needed. The code of (upcoming) compat_sys_epoll_pwait takes care of both, with a smart compile-time check to wire sys_epoll_wait or compat_sys_epoll_wait, depending on the need of the struct epoll_event compat handling. So yes, compat_sys_epoll_pwait is needed. - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sun, Feb 11, 2007 at 04:33:41PM +0100, David Woodhouse wrote: On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh well, too late. Indeed. That was the example I was thinking of when I suggested the no new syscalls without _simultaneous_ compat version rule. The need for a compat ABI is not always obvious. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sun, Feb 11, 2007 at 05:14:46PM +0100, Heiko Carstens wrote: Hmm.. so you don't need to do some fancy compat conversion for the sigset_t that gets passed? Why is that? I don't get it... Ah, I finally get your point. Yes, that needs conversion. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, 10 Feb 2007, Ralf Baechle wrote: > Unfortunately struct epoll_event contains a gap so it bets on identical > padding rules between native and compat ABI and anyway, padding is wasted > space so the struct members should have been swapped when this structure > was created. Oh well, too late. You really should have needed padding in there, since even if you swapped the members, sizeof(struct epoll_event) would still need to be 16, if alignof(u64) == 8. Either adding an extra auxilliary u32, or make the two members be u64, would have been ok. I'll be posting a patch that adds the compat_ layer for epoll in kernel/compat.c. Architectures that needs it (currently only ARM-EABI and IA64 use a compat code for epoll), should wire them up. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > Which remembers me that I think that MIPS is using the non-compat version > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > syscall for some reason. Dunno. > > It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree > there there's 32 bits of padding between the fields of this structure: > > struct epoll_event { > __u32 events; > __u64 data; > }; > > I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 > ABI is different then it would need the compat syscall. That is correct - and apparently for all ABIs because I wasn't able to find a compat_sys_epoll_pwait at all. Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh well, too late. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Ralf Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S index b4aa875..5993262 100644 --- a/arch/x86_64/ia32/ia32entry.S +++ b/arch/x86_64/ia32/ia32entry.S @@ -718,4 +718,5 @@ ia32_sys_call_table: .quad compat_sys_vmsplice .quad compat_sys_move_pages .quad sys_getcpu + .quad sys_epoll_pwait ia32_syscall_end: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: > > I'm getting fed up of holding onto hundreds of patches against subsystem > trees, sending them over and over again seeing and nothing happen. I sent > 242 > patches out to subsystem maintainers on Monday and look at what's still here. > > agpgart-allow-drm-populated-agp-memory-types-tidy.patch > remove-hotplug-cpu-crap-from-cpufreq.patch > rewrite-lock-in-cpufreq-to-eliminate-cpufreq-hotplug-related-issues.patch > ondemand-governor-restructure-the-work-callback.patch > ondemand-governor-use-new-cpufreq-rwsem-locking-in-work-callback.patch > cpu_freq_table-shouldnt-be-a-def_tristate.patch > > -> davej Apologies, I suck. I'll dispose of these appropriately tonight. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch
On Sat, Feb 10, 2007 at 10:58:58AM +0100, Heiko Carstens wrote: > Alasdair, is dm already fixed or is there any chance that it will > ever get fixed? I still expect us to get this changed within the next few months. We've dealt with the changes necessary to the crypt target for this. The final problem remaining is the core dm bio splitting code, and there's a related locking problem in that code to tackle at the same time. Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Frederik Deweerdt wrote: How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is not true, the "static const int" don't use extra space, they get optimized away by the compiler (see http://lkml.org/lkml/2007/2/9/106). gcc 3.2 should be tested as well, that is still supported by the kernel, and versions before 3.4 did not have unit-at-a-time optimizations. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Saturday 10 February 2007 14:48, Alan wrote: > > Well it's a technical issue -- it conflicts with the machine check > > code that is already implemented by stealing away its events. > > You would first need a CONFIG_MCE=n on x86-64 at least, otherwise > > one of them will be unhappy. > > That is a fair point, albeit after far too long sitting stuck in the tree. I'm pretty sure I mentioned it earlier already. > I'll have a look into this a bit further, probably MCE_K8 should feed off > the output of the MCE driver. You could probably write a simple edac driver that just feeds of the events mce.c generates and presents that as the EDAC drivers. Currently the user space device is the only consumer, but it wouldn't be hard to full it off to other kernel users. Possibly keeping the existing code that reads the DIMMs and then reads the address map of the NB and match that, then you get the same output. [However see below -- i think matching it to SMBIOS using the address is a lot more useful for the user in the end] > > > The other issue is that the existing code does everything EDAC > > K8 does already perfectly fine, just in a small fraction of > > the code. > > Which is false. It provided a totally inconsistent interface to user > space, while the EDAC layer provides the consistency many people need and > want. I still don't get that argument because unlike mce.c+mcelog EDAC cannot actually tell you where the DIMM that failed is located on your motherboard. As far as i can make it out it's only useful for people who either have full schematics of their motherboard and know how to read them or did a full try'n'error of all combinations run once to figure out which channel is located where. Somehow I cannot imagine either of that is very common in "enterprises" ;-) Ok one argument was that some LinuxBIOS users don't seem to set up these tables and have the necessary information at hand for their custom cluster hardware, but that's still a weird uncommon case and it would be far better if they just fixed LB. > Also unless it has changed remarkably the MCE driver doesn't do > scrubbing which is needed in software on some chip revisions. True, adding that might be a good idea. [Although I guess that could be done with a small user utility using /dev/mem though if you really wanted it?] One thing EDAC also does that mcelog doesn't is decode the ECC syndromes -- but I haven't figured out a use case yet where that is actually useful to know afterwards. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
> Well it's a technical issue -- it conflicts with the machine check > code that is already implemented by stealing away its events. > You would first need a CONFIG_MCE=n on x86-64 at least, otherwise > one of them will be unhappy. That is a fair point, albeit after far too long sitting stuck in the tree. I'll have a look into this a bit further, probably MCE_K8 should feed off the output of the MCE driver. > The other issue is that the existing code does everything EDAC > K8 does already perfectly fine, just in a small fraction of > the code. Which is false. It provided a totally inconsistent interface to user space, while the EDAC layer provides the consistency many people need and want. Also unless it has changed remarkably the MCE driver doesn't do scrubbing which is needed in software on some chip revisions. The MCE driver is small, neat, incomplete for some cases and different to all the other platforms as they use off CPU memory controllers. Its ideal for a lot of uses but not big enterprise systems. Thats why we need both. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 12:42:41PM +0100, Arnd Bergmann wrote: > On Friday 09 February 2007 12:24, Arjan van de Ven wrote: > > > > On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > > > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > > > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; > > > +static const int __deprecated SA_SHIRQ = IRQF_SHARED; > > > +static const int __deprecated SA_PROBEIRQ = IRQF_PROBE_SHARED; > > > +static const int __deprecated SA_PERCPU = IRQF_PERCPU; > > > + > > > +static const int __deprecated SA_TRIGGER_LOW = IRQF_TRIGGER_LOW; > > > +static const int __deprecated SA_TRIGGER_HIGH = IRQF_TRIGGER_HIGH; > > > +static const int __deprecated SA_TRIGGER_FALLING = IRQF_TRIGGER_FALLING; > > > +static const int __deprecated SA_TRIGGER_RISING = IRQF_TRIGGER_RISING; > > > +static const int __deprecated SA_TRIGGER_MASK = IRQF_TRIGGER_MASK; > > > > this will include these in every .o file for which the .c file includes > > the header. NOT GOOD(tm) > > > > How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is not true, the "static const int" don't use extra space, they get optimized away by the compiler (see http://lkml.org/lkml/2007/2/9/106). Regards, Frederik > > Mark SA_* constants as deprecated > > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> > > --- a/include/linux/interrupt.h > +++ b/include/linux/interrupt.h > @@ -53,17 +53,19 @@ > * Migration helpers. Scheduled for removal in 1/2007 > * Do not use for new code ! > */ > -#define SA_INTERRUPT IRQF_DISABLED > -#define SA_SAMPLE_RANDOM IRQF_SAMPLE_RANDOM > -#define SA_SHIRQ IRQF_SHARED > -#define SA_PROBEIRQ IRQF_PROBE_SHARED > -#define SA_PERCPUIRQF_PERCPU > - > -#define SA_TRIGGER_LOW IRQF_TRIGGER_LOW > -#define SA_TRIGGER_HIGH IRQF_TRIGGER_HIGH > -#define SA_TRIGGER_FALLING IRQF_TRIGGER_FALLING > -#define SA_TRIGGER_RISINGIRQF_TRIGGER_RISING > -#define SA_TRIGGER_MASK IRQF_TRIGGER_MASK > +typedef unsigned int __deprecated deprecated_irqf; > + > +#define SA_INTERRUPT ((deprecated_irqf)IRQF_DISABLED) > +#define SA_SAMPLE_RANDOM ((deprecated_irqf)IRQF_SAMPLE_RANDOM) > +#define SA_SHIRQ ((deprecated_irqf)IRQF_SHARED) > +#define SA_PROBEIRQ ((deprecated_irqf)IRQF_PROBE_SHARED) > +#define SA_PERCPU((deprecated_irqf)IRQF_PERCPU) > + > +#define SA_TRIGGER_LOW ((deprecated_irqf)IRQF_TRIGGER_LOW) > +#define SA_TRIGGER_HIGH ((deprecated_irqf)IRQF_TRIGGER_HIGH) > +#define SA_TRIGGER_FALLING ((deprecated_irqf)IRQF_TRIGGER_FALLING) > +#define SA_TRIGGER_RISING((deprecated_irqf)IRQF_TRIGGER_RISING) > +#define SA_TRIGGER_MASK ((deprecated_irqf)IRQF_TRIGGER_MASK) > > typedef irqreturn_t (*irq_handler_t)(int, void *); > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Alan <[EMAIL PROTECTED]> writes: > Please just push the EDAC K8 stuff. Andi will say "no" from now until the > end of time, but end users want it, distributions want it, and Andi is > not the EDAC maintainer so should consider himself overruled on what > isn't a technical issue but a personal political viewpoint. Well it's a technical issue -- it conflicts with the machine check code that is already implemented by stealing away its events. You would first need a CONFIG_MCE=n on x86-64 at least, otherwise one of them will be unhappy. The other issue is that the existing code does everything EDAC K8 does already perfectly fine, just in a small fraction of the code. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
David Woodhouse <[EMAIL PROTECTED]> writes: > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > lutimesat-simplify-utime2.patch > > lutimesat-extend-do_utimes-with-flags.patch > > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > > > Do we want this? Ulrich says so. Will merge, I guess. > > I would strongly recommend that in the general case, you don't merge new > system calls unless the corresponding compat_ system call is > implemented. ... and there is a manpage ready to submit to manpages. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Friday 09 February 2007 12:24, Arjan van de Ven wrote: > > On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; > > +static const int __deprecated SA_SHIRQ = IRQF_SHARED; > > +static const int __deprecated SA_PROBEIRQ = IRQF_PROBE_SHARED; > > +static const int __deprecated SA_PERCPU = IRQF_PERCPU; > > + > > +static const int __deprecated SA_TRIGGER_LOW = IRQF_TRIGGER_LOW; > > +static const int __deprecated SA_TRIGGER_HIGH = IRQF_TRIGGER_HIGH; > > +static const int __deprecated SA_TRIGGER_FALLING = IRQF_TRIGGER_FALLING; > > +static const int __deprecated SA_TRIGGER_RISING = IRQF_TRIGGER_RISING; > > +static const int __deprecated SA_TRIGGER_MASK = IRQF_TRIGGER_MASK; > > this will include these in every .o file for which the .c file includes > the header. NOT GOOD(tm) > How about this one instead then: Mark SA_* constants as deprecated Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -53,17 +53,19 @@ * Migration helpers. Scheduled for removal in 1/2007 * Do not use for new code ! */ -#define SA_INTERRUPT IRQF_DISABLED -#define SA_SAMPLE_RANDOM IRQF_SAMPLE_RANDOM -#define SA_SHIRQ IRQF_SHARED -#define SA_PROBEIRQIRQF_PROBE_SHARED -#define SA_PERCPU IRQF_PERCPU - -#define SA_TRIGGER_LOW IRQF_TRIGGER_LOW -#define SA_TRIGGER_HIGHIRQF_TRIGGER_HIGH -#define SA_TRIGGER_FALLING IRQF_TRIGGER_FALLING -#define SA_TRIGGER_RISING IRQF_TRIGGER_RISING -#define SA_TRIGGER_MASKIRQF_TRIGGER_MASK +typedef unsigned int __deprecated deprecated_irqf; + +#define SA_INTERRUPT ((deprecated_irqf)IRQF_DISABLED) +#define SA_SAMPLE_RANDOM ((deprecated_irqf)IRQF_SAMPLE_RANDOM) +#define SA_SHIRQ ((deprecated_irqf)IRQF_SHARED) +#define SA_PROBEIRQ((deprecated_irqf)IRQF_PROBE_SHARED) +#define SA_PERCPU ((deprecated_irqf)IRQF_PERCPU) + +#define SA_TRIGGER_LOW ((deprecated_irqf)IRQF_TRIGGER_LOW) +#define SA_TRIGGER_HIGH((deprecated_irqf)IRQF_TRIGGER_HIGH) +#define SA_TRIGGER_FALLING ((deprecated_irqf)IRQF_TRIGGER_FALLING) +#define SA_TRIGGER_RISING ((deprecated_irqf)IRQF_TRIGGER_RISING) +#define SA_TRIGGER_MASK((deprecated_irqf)IRQF_TRIGGER_MASK) typedef irqreturn_t (*irq_handler_t)(int, void *); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree there there's 32 bits of padding between the fields of this structure: struct epoll_event { __u32 events; __u64 data; }; I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 ABI is different then it would need the compat syscall. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, Feb 09, 2007 at 02:50:12PM -0800, Davide Libenzi wrote: > On Fri, 9 Feb 2007, David Woodhouse wrote: > > > On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: > > > > I would strongly recommend that in the general case, you don't merge new > > > > system calls unless the corresponding compat_ system call is > > > > implemented. > > > > > > Good point. > > > > It's a _damn_ good point, but I see we went ahead and merged > > sys_epoll_pwait without it anyway -- despite the fact that it's > > include/linux/eventpoll.h which contains the example of why we should > > think first :) > > > > I think I even threw together an untested implementation of > > compat_sys_epoll_pwait() at one point to assist with that task, but it > > didn't seem to help much. > > Damn! I always forget. Doing it right now ... Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: > drivers-mdc-use-array_size-macro-when-appropriate.patch > md-dm-reduce-stack-usage-with-stacked-block-devices.patch > > -> neilb > > (The second one is getting idiotic. When are we going to fix this??) Since it was me who asked to have the stack usage reduced and Neil was kind enough to fix this, I'm wondering what the state of dm is. I think more than a year ago we had this: Alasdair G Kergon <[EMAIL PROTECTED]> said: I can see nothing wrong with this in principle. For device-mapper at the moment though it's essential that, while the bio mappings may now get delayed, they still get processed in exactly the same order as they were passed to generic_make_request(). My main concern is whether the timing changes implicit in this patch will make the rare data-corrupting races in the existing snapshot code more likely. (I'm working on a fix for these races, but the unfinished patch is already several hundred lines long.) It would be helpful if some people on this mailing list would test this patch in various scenarios and report back. Alasdair, is dm already fixed or is there any chance that it will ever get fixed? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch
On Sat, Feb 10, 2007 at 10:58:58AM +0100, Heiko Carstens wrote: Alasdair, is dm already fixed or is there any chance that it will ever get fixed? I still expect us to get this changed within the next few months. We've dealt with the changes necessary to the crypt target for this. The final problem remaining is the core dm bio splitting code, and there's a related locking problem in that code to tackle at the same time. Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: I'm getting fed up of holding onto hundreds of patches against subsystem trees, sending them over and over again seeing and nothing happen. I sent 242 patches out to subsystem maintainers on Monday and look at what's still here. agpgart-allow-drm-populated-agp-memory-types-tidy.patch remove-hotplug-cpu-crap-from-cpufreq.patch rewrite-lock-in-cpufreq-to-eliminate-cpufreq-hotplug-related-issues.patch ondemand-governor-restructure-the-work-callback.patch ondemand-governor-use-new-cpufreq-rwsem-locking-in-work-callback.patch cpu_freq_table-shouldnt-be-a-def_tristate.patch - davej Apologies, I suck. I'll dispose of these appropriately tonight. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Ralf Signed-off-by: Ralf Baechle [EMAIL PROTECTED] diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S index b4aa875..5993262 100644 --- a/arch/x86_64/ia32/ia32entry.S +++ b/arch/x86_64/ia32/ia32entry.S @@ -718,4 +718,5 @@ ia32_sys_call_table: .quad compat_sys_vmsplice .quad compat_sys_move_pages .quad sys_getcpu + .quad sys_epoll_pwait ia32_syscall_end: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree there there's 32 bits of padding between the fields of this structure: struct epoll_event { __u32 events; __u64 data; }; I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 ABI is different then it would need the compat syscall. That is correct - and apparently for all ABIs because I wasn't able to find a compat_sys_epoll_pwait at all. Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh well, too late. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, 10 Feb 2007, Ralf Baechle wrote: Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh well, too late. You really should have needed padding in there, since even if you swapped the members, sizeof(struct epoll_event) would still need to be 16, if alignof(u64) == 8. Either adding an extra auxilliary u32, or make the two members be u64, would have been ok. I'll be posting a patch that adds the compat_ layer for epoll in kernel/compat.c. Architectures that needs it (currently only ARM-EABI and IA64 use a compat code for epoll), should wire them up. - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: drivers-mdc-use-array_size-macro-when-appropriate.patch md-dm-reduce-stack-usage-with-stacked-block-devices.patch - neilb (The second one is getting idiotic. When are we going to fix this??) Since it was me who asked to have the stack usage reduced and Neil was kind enough to fix this, I'm wondering what the state of dm is. I think more than a year ago we had this: Alasdair G Kergon [EMAIL PROTECTED] said: I can see nothing wrong with this in principle. For device-mapper at the moment though it's essential that, while the bio mappings may now get delayed, they still get processed in exactly the same order as they were passed to generic_make_request(). My main concern is whether the timing changes implicit in this patch will make the rare data-corrupting races in the existing snapshot code more likely. (I'm working on a fix for these races, but the unfinished patch is already several hundred lines long.) It would be helpful if some people on this mailing list would test this patch in various scenarios and report back. Alasdair, is dm already fixed or is there any chance that it will ever get fixed? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, Feb 09, 2007 at 02:50:12PM -0800, Davide Libenzi wrote: On Fri, 9 Feb 2007, David Woodhouse wrote: On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: I would strongly recommend that in the general case, you don't merge new system calls unless the corresponding compat_ system call is implemented. Good point. It's a _damn_ good point, but I see we went ahead and merged sys_epoll_pwait without it anyway -- despite the fact that it's include/linux/eventpoll.h which contains the example of why we should think first :) I think I even threw together an untested implementation of compat_sys_epoll_pwait() at one point to assist with that task, but it didn't seem to help much. Damn! I always forget. Doing it right now ... Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree there there's 32 bits of padding between the fields of this structure: struct epoll_event { __u32 events; __u64 data; }; I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 ABI is different then it would need the compat syscall. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Friday 09 February 2007 12:24, Arjan van de Ven wrote: On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; +static const int __deprecated SA_SHIRQ = IRQF_SHARED; +static const int __deprecated SA_PROBEIRQ = IRQF_PROBE_SHARED; +static const int __deprecated SA_PERCPU = IRQF_PERCPU; + +static const int __deprecated SA_TRIGGER_LOW = IRQF_TRIGGER_LOW; +static const int __deprecated SA_TRIGGER_HIGH = IRQF_TRIGGER_HIGH; +static const int __deprecated SA_TRIGGER_FALLING = IRQF_TRIGGER_FALLING; +static const int __deprecated SA_TRIGGER_RISING = IRQF_TRIGGER_RISING; +static const int __deprecated SA_TRIGGER_MASK = IRQF_TRIGGER_MASK; this will include these in every .o file for which the .c file includes the header. NOT GOOD(tm) How about this one instead then: Mark SA_* constants as deprecated Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -53,17 +53,19 @@ * Migration helpers. Scheduled for removal in 1/2007 * Do not use for new code ! */ -#define SA_INTERRUPT IRQF_DISABLED -#define SA_SAMPLE_RANDOM IRQF_SAMPLE_RANDOM -#define SA_SHIRQ IRQF_SHARED -#define SA_PROBEIRQIRQF_PROBE_SHARED -#define SA_PERCPU IRQF_PERCPU - -#define SA_TRIGGER_LOW IRQF_TRIGGER_LOW -#define SA_TRIGGER_HIGHIRQF_TRIGGER_HIGH -#define SA_TRIGGER_FALLING IRQF_TRIGGER_FALLING -#define SA_TRIGGER_RISING IRQF_TRIGGER_RISING -#define SA_TRIGGER_MASKIRQF_TRIGGER_MASK +typedef unsigned int __deprecated deprecated_irqf; + +#define SA_INTERRUPT ((deprecated_irqf)IRQF_DISABLED) +#define SA_SAMPLE_RANDOM ((deprecated_irqf)IRQF_SAMPLE_RANDOM) +#define SA_SHIRQ ((deprecated_irqf)IRQF_SHARED) +#define SA_PROBEIRQ((deprecated_irqf)IRQF_PROBE_SHARED) +#define SA_PERCPU ((deprecated_irqf)IRQF_PERCPU) + +#define SA_TRIGGER_LOW ((deprecated_irqf)IRQF_TRIGGER_LOW) +#define SA_TRIGGER_HIGH((deprecated_irqf)IRQF_TRIGGER_HIGH) +#define SA_TRIGGER_FALLING ((deprecated_irqf)IRQF_TRIGGER_FALLING) +#define SA_TRIGGER_RISING ((deprecated_irqf)IRQF_TRIGGER_RISING) +#define SA_TRIGGER_MASK((deprecated_irqf)IRQF_TRIGGER_MASK) typedef irqreturn_t (*irq_handler_t)(int, void *); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
David Woodhouse [EMAIL PROTECTED] writes: On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: lutimesat-simplify-utime2.patch lutimesat-extend-do_utimes-with-flags.patch lutimesat-actual-syscall-and-wire-up-on-i386.patch Do we want this? Ulrich says so. Will merge, I guess. I would strongly recommend that in the general case, you don't merge new system calls unless the corresponding compat_ system call is implemented. ... and there is a manpage ready to submit to manpages. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Alan [EMAIL PROTECTED] writes: Please just push the EDAC K8 stuff. Andi will say no from now until the end of time, but end users want it, distributions want it, and Andi is not the EDAC maintainer so should consider himself overruled on what isn't a technical issue but a personal political viewpoint. Well it's a technical issue -- it conflicts with the machine check code that is already implemented by stealing away its events. You would first need a CONFIG_MCE=n on x86-64 at least, otherwise one of them will be unhappy. The other issue is that the existing code does everything EDAC K8 does already perfectly fine, just in a small fraction of the code. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, Feb 10, 2007 at 12:42:41PM +0100, Arnd Bergmann wrote: On Friday 09 February 2007 12:24, Arjan van de Ven wrote: On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; +static const int __deprecated SA_SHIRQ = IRQF_SHARED; +static const int __deprecated SA_PROBEIRQ = IRQF_PROBE_SHARED; +static const int __deprecated SA_PERCPU = IRQF_PERCPU; + +static const int __deprecated SA_TRIGGER_LOW = IRQF_TRIGGER_LOW; +static const int __deprecated SA_TRIGGER_HIGH = IRQF_TRIGGER_HIGH; +static const int __deprecated SA_TRIGGER_FALLING = IRQF_TRIGGER_FALLING; +static const int __deprecated SA_TRIGGER_RISING = IRQF_TRIGGER_RISING; +static const int __deprecated SA_TRIGGER_MASK = IRQF_TRIGGER_MASK; this will include these in every .o file for which the .c file includes the header. NOT GOOD(tm) How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is not true, the static const int don't use extra space, they get optimized away by the compiler (see http://lkml.org/lkml/2007/2/9/106). Regards, Frederik Mark SA_* constants as deprecated Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -53,17 +53,19 @@ * Migration helpers. Scheduled for removal in 1/2007 * Do not use for new code ! */ -#define SA_INTERRUPT IRQF_DISABLED -#define SA_SAMPLE_RANDOM IRQF_SAMPLE_RANDOM -#define SA_SHIRQ IRQF_SHARED -#define SA_PROBEIRQ IRQF_PROBE_SHARED -#define SA_PERCPUIRQF_PERCPU - -#define SA_TRIGGER_LOW IRQF_TRIGGER_LOW -#define SA_TRIGGER_HIGH IRQF_TRIGGER_HIGH -#define SA_TRIGGER_FALLING IRQF_TRIGGER_FALLING -#define SA_TRIGGER_RISINGIRQF_TRIGGER_RISING -#define SA_TRIGGER_MASK IRQF_TRIGGER_MASK +typedef unsigned int __deprecated deprecated_irqf; + +#define SA_INTERRUPT ((deprecated_irqf)IRQF_DISABLED) +#define SA_SAMPLE_RANDOM ((deprecated_irqf)IRQF_SAMPLE_RANDOM) +#define SA_SHIRQ ((deprecated_irqf)IRQF_SHARED) +#define SA_PROBEIRQ ((deprecated_irqf)IRQF_PROBE_SHARED) +#define SA_PERCPU((deprecated_irqf)IRQF_PERCPU) + +#define SA_TRIGGER_LOW ((deprecated_irqf)IRQF_TRIGGER_LOW) +#define SA_TRIGGER_HIGH ((deprecated_irqf)IRQF_TRIGGER_HIGH) +#define SA_TRIGGER_FALLING ((deprecated_irqf)IRQF_TRIGGER_FALLING) +#define SA_TRIGGER_RISING((deprecated_irqf)IRQF_TRIGGER_RISING) +#define SA_TRIGGER_MASK ((deprecated_irqf)IRQF_TRIGGER_MASK) typedef irqreturn_t (*irq_handler_t)(int, void *); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Well it's a technical issue -- it conflicts with the machine check code that is already implemented by stealing away its events. You would first need a CONFIG_MCE=n on x86-64 at least, otherwise one of them will be unhappy. That is a fair point, albeit after far too long sitting stuck in the tree. I'll have a look into this a bit further, probably MCE_K8 should feed off the output of the MCE driver. The other issue is that the existing code does everything EDAC K8 does already perfectly fine, just in a small fraction of the code. Which is false. It provided a totally inconsistent interface to user space, while the EDAC layer provides the consistency many people need and want. Also unless it has changed remarkably the MCE driver doesn't do scrubbing which is needed in software on some chip revisions. The MCE driver is small, neat, incomplete for some cases and different to all the other platforms as they use off CPU memory controllers. Its ideal for a lot of uses but not big enterprise systems. Thats why we need both. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Saturday 10 February 2007 14:48, Alan wrote: Well it's a technical issue -- it conflicts with the machine check code that is already implemented by stealing away its events. You would first need a CONFIG_MCE=n on x86-64 at least, otherwise one of them will be unhappy. That is a fair point, albeit after far too long sitting stuck in the tree. I'm pretty sure I mentioned it earlier already. I'll have a look into this a bit further, probably MCE_K8 should feed off the output of the MCE driver. You could probably write a simple edac driver that just feeds of the events mce.c generates and presents that as the EDAC drivers. Currently the user space device is the only consumer, but it wouldn't be hard to full it off to other kernel users. Possibly keeping the existing code that reads the DIMMs and then reads the address map of the NB and match that, then you get the same output. [However see below -- i think matching it to SMBIOS using the address is a lot more useful for the user in the end] The other issue is that the existing code does everything EDAC K8 does already perfectly fine, just in a small fraction of the code. Which is false. It provided a totally inconsistent interface to user space, while the EDAC layer provides the consistency many people need and want. I still don't get that argument because unlike mce.c+mcelog EDAC cannot actually tell you where the DIMM that failed is located on your motherboard. As far as i can make it out it's only useful for people who either have full schematics of their motherboard and know how to read them or did a full try'n'error of all combinations run once to figure out which channel is located where. Somehow I cannot imagine either of that is very common in enterprises ;-) Ok one argument was that some LinuxBIOS users don't seem to set up these tables and have the necessary information at hand for their custom cluster hardware, but that's still a weird uncommon case and it would be far better if they just fixed LB. Also unless it has changed remarkably the MCE driver doesn't do scrubbing which is needed in software on some chip revisions. True, adding that might be a good idea. [Although I guess that could be done with a small user utility using /dev/mem though if you really wanted it?] One thing EDAC also does that mcelog doesn't is decode the ECC syndromes -- but I haven't figured out a use case yet where that is actually useful to know afterwards. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Frederik Deweerdt wrote: How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is not true, the static const int don't use extra space, they get optimized away by the compiler (see http://lkml.org/lkml/2007/2/9/106). gcc 3.2 should be tested as well, that is still supported by the kernel, and versions before 3.4 did not have unit-at-a-time optimizations. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
> From: Russell King > Newsgroups: gmane.linux.kernel > Subject: Re: -mm merge plans for 2.6.21 > Date: Fri, 9 Feb 2007 22:03:27 + [] > However: > > sys_foo(int a, int c, unsigned long long b, unsigned long long d) > > is entirely reasonable and leaves us with spare room for one additional > 32-bit arg to be passed. > >> Is that actually written anywhere, and does anyone bother to check? > > Mostly mailing list archives I'd guess. As far as anyone bothering > to check, that's me when I'm aware of new syscalls... which typically > happens a long time after the syscalls have been introduced on x86 > etc. Why not to have "the most large argument first" rule here? sys_bar(largest,..., larger,..., smaller,..., small); Put it in Documentation/ABI/README and bother only, when compiller will bark on -mm tree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Sat, 10 Feb 2007 02:15:11 +0100 Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Fri, 9 Feb 2007 19:37:53 + > > Alan <[EMAIL PROTECTED]> wrote: > > > >> Please just push the EDAC K8 stuff. > > > > OK. > > > >> Andi will say "no" from now until the > >> end of time, but end users want it, distributions want it, and Andi is > >> not the EDAC maintainer so should consider himself overruled on what > >> isn't a technical issue but a personal political viewpoint. > > > > I'll just tell him I sent it by accident. > > Could you please merge ACPI-DSDT-in-initrd for the same reasons? > I don't know what that is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Andrew Morton wrote: > On Fri, 9 Feb 2007 19:37:53 + > Alan <[EMAIL PROTECTED]> wrote: > >> Please just push the EDAC K8 stuff. > > OK. > >> Andi will say "no" from now until the >> end of time, but end users want it, distributions want it, and Andi is >> not the EDAC maintainer so should consider himself overruled on what >> isn't a technical issue but a personal political viewpoint. > > I'll just tell him I sent it by accident. Could you please merge ACPI-DSDT-in-initrd for the same reasons? Regards, Carl-Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 9 Feb 2007, David Woodhouse wrote: > On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: > > > I would strongly recommend that in the general case, you don't merge new > > > system calls unless the corresponding compat_ system call is > > > implemented. > > > > Good point. > > It's a _damn_ good point, but I see we went ahead and merged > sys_epoll_pwait without it anyway -- despite the fact that it's > include/linux/eventpoll.h which contains the example of why we should > think first :) > > I think I even threw together an untested implementation of > compat_sys_epoll_pwait() at one point to assist with that task, but it > didn't seem to help much. Damn! I always forget. Doing it right now ... - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 2007-02-09 at 22:12 +, David Woodhouse wrote: > > We could _also_ do with a way to warn about unimplemented syscalls on > any given architecture. I'm thinking about something along the lines > of > a kernel/syscalls.c containing nothing but... > > #include > > #ifndef __NR_sys_foo > #warning The sys_foo system call is not implemented on this > architecture > #endif > > Ideally, that wants to be auto-generated from the union of all > files, but in practice I suspect we could do it just > from . Even I usually manage to add new syscalls on > i386 after I've done PowerPC. Realistically speaking, I'm not going to have time to do anything useful with this before I disappear for a week starting tomorrow. But in case it helps, I'll throw this in to see if it inspires anyone... ( echo -e "#include \n#include " ; sed -n '/^#define/s/[^_]*__NR_ \([^[:space:]]*\).*/#if !defined (__NR_\1) \&\& !defined (__IGNORE_ \1)\n#warning System call \1 is not implemented\n#endif/p' include/asm-i386/unistd.h ) > kernel/syscalls.c Coupled with an include/optional-syscalls.h which defines __IGNORE_vm86, __IGNORE_vm86old and then on 64-bit machines a bunch more __IGNORE_stat64 et al., that should mostly do the trick... -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Andrew Morton a écrit : factor-outstanding-i-o-error-handling.patch factor-outstanding-i-o-error-handling-tidy.patch I still like them. But the original problem is still present. sync_sb_inodes-propagate-errors.patch You explained in http://lkml.org/lkml/2007/1/2/238 that the mapping flags should be set at the lowest level, but with this change I have a hard time choosing a place to stick it. I don't like when a function both sets the mapping flags and returns an error code, I think it should be mutually exclusive, so that we know what to do (propagate the return code?) and what to expect (are the mapping flags up to date?), which seemed to be the case before this patch. For instance there is no point in propagating an error return code up to sys_sync() as it can only drop it. The call trace that cleared the flags, the origin of the problem, is: void do_sync(1) void sync_inodes(1) void __sync_inodes(1) void sync_inodes_sb(sb, 1) void sync_sb_inodes(sb, WB_SYNC_ALL) int __writeback_single_inode(inode, WB_SYNC_ALL) int __sync_single_inode(inode, WB_SYNC_ALL) int filemap_fdatawait(mapping) int wait_on_page_writeback_range(mapping) int test_and_clear(...) re-setting the flag at a too low level, would mean it is still set after a msync() or fsync() that could return the status to its caller. My interpretation is that low level functions up to __writeback_single_inode() can be used by fsync() and the like that can return the error to their caller, unlike high level functions starting at sync_sb_inodes() that don't need a return value as their caller can do nothing with it. So re-setting the flag in sync_sb_inodes() just after __writeback_single_inode() looks right to me, and I propose the exact same patch as the first time. block_write_full_page-handle-enospc.patch It seems to me that __block_write_full_page is always called more or less directly from __mpage_writepage, and the latter handles enospc in the mapping flags. So I am not sure this patch is needed. Thanks. -- Guillaume I/O errors could go unnoticed when syncing, for example the following code could write a file bigger than 10Mib on a 10Mib filesystem. With this patch, msync() will report the error originally encountered by sync(). Tuning the number of sync may be needed to reproduce the bug. make_file.c: #include #include #include #include #include #define NR_SYNC 3 /* Adjust me if needed */ #define SIZE ((10 << 20) + (100 << 10)) int main(void) { int i, fd; char *mapping; fd = open("mnt/file", O_RDWR | O_CREAT, 0600); if (fd < 0) { perror("open"); return 1; } if (ftruncate(fd, SIZE) < 0) { perror("ftruncate"); return 1; } mapping = mmap(NULL, SIZE, PROT_WRITE, MAP_SHARED, fd, 0); if (mapping == MAP_FAILED) { perror("mmap"); return 1; } memset(mapping, 0xFF, SIZE); for (i = 0; i < NR_SYNC; i++) sync(); if (msync(mapping, SIZE, MS_SYNC) < 0) { perror("msync"); return 1; } if (close(fd) < 0) { perror("close"); return 1; } puts("File written successfully => bad!\n"); return 0; } #!/bin/sh dd if=/dev/zero of=fs.10M bs=10M count=0 seek=1 mkfs.ext2 -qF fs.10M mkdir mnt mount fs.10M mnt -o loop ./make_file Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]> --- fs-writeback.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff -r ecb3a0d111ec fs/fs-writeback.c --- a/fs/fs-writeback.c Fri Feb 09 15:31:50 2007 +0100 +++ b/fs/fs-writeback.c Fri Feb 09 23:10:47 2007 +0100 @@ -327,6 +327,7 @@ sync_sb_inodes(struct super_block *sb, s struct address_space *mapping = inode->i_mapping; struct backing_dev_info *bdi = mapping->backing_dev_info; long pages_skipped; + int ret; if (!bdi_cap_writeback_dirty(bdi)) { list_move(>i_list, >s_dirty); @@ -376,7 +377,8 @@ sync_sb_inodes(struct super_block *sb, s BUG_ON(inode->i_state & I_FREEING); __iget(inode); pages_skipped = wbc->pages_skipped; - __writeback_single_inode(inode, wbc); + ret = __writeback_single_inode(inode, wbc); + mapping_set_error(mapping, ret); if (wbc->sync_mode == WB_SYNC_HOLD) { inode->dirtied_when = jiffies; list_move(>i_list, >s_dirty);
Re: -mm merge plans for 2.6.21
On Fri, 2007-02-09 at 22:03 +, Russell King wrote: > > Is that actually written anywhere, and does anyone bother to check? > > Mostly mailing list archives I'd guess. As far as anyone bothering > to check, that's me when I'm aware of new syscalls... which typically > happens a long time after the syscalls have been introduced on x86 > etc. I suspect we could do with a Documentation/syscalls.txt collecting such rules from various architectures. We could _also_ do with a way to warn about unimplemented syscalls on any given architecture. I'm thinking about something along the lines of a kernel/syscalls.c containing nothing but... #include #ifndef __NR_sys_foo #warning The sys_foo system call is not implemented on this architecture #endif Ideally, that wants to be auto-generated from the union of all files, but in practice I suspect we could do it just from . Even I usually manage to add new syscalls on i386 after I've done PowerPC. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, Feb 09, 2007 at 02:00:49PM -0800, Andrew Morton wrote: > +asmlinkage long sys_lio_submit(aio_context_t ctx_id, int mode, long nr, > + struct iocb __user * __user *iocbpp, struct sigevent __user *event) Not a problem. (r0 := ctx_id, r1 := mode, r2 := nr, r3 := iocbpp, r4 := event) Thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, Feb 09, 2007 at 09:53:19PM +, David Woodhouse wrote: > On Fri, 2007-02-09 at 21:49 +, Russell King wrote: > > urgh, new system calls... wonder if they fit in the ARM ABI... Looks > > fine. > > Can you elucidate on _what_ you just checked for? > > There was something about alignment of 64-bit arguments to syscalls > which affects MIPS and/or ARM which I can't quite remember-- It's something like that. > something > about putting it them arguments in either an even-numbered or > odd-numbered position to make it work nicely. We have a maximum of 7 32-bit registers to pass system call arguments. In EABI, 64-bit arguments must be aligned to an even-numbered register (starting at zero). In OABI, 64-bit arguments do not have this restriction. So, for EABI: sys_foo(int a, unsigned long long b, int c, unsigned long long d) would allocate 'a' into r0, 'b' into r2,r3, 'c' into r4, and 'd' into r6, and oops we're out of registers - so the above syscall prototype can't be supported on ARM. However: sys_foo(int a, int c, unsigned long long b, unsigned long long d) is entirely reasonable and leaves us with spare room for one additional 32-bit arg to be passed. > Is that actually written anywhere, and does anyone bother to check? Mostly mailing list archives I'd guess. As far as anyone bothering to check, that's me when I'm aware of new syscalls... which typically happens a long time after the syscalls have been introduced on x86 etc. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 9 Feb 2007 21:49:44 + Russell King <[EMAIL PROTECTED]> wrote: > On Fri, Feb 09, 2007 at 01:45:16PM -0800, Andrew Morton wrote: > > On Fri, 09 Feb 2007 17:35:35 + > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > > > lutimesat-simplify-utime2.patch > > > > lutimesat-extend-do_utimes-with-flags.patch > > > > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > > > > > > > Do we want this? Ulrich says so. Will merge, I guess. > > > > > > I would strongly recommend that in the general case, you don't merge new > > > system calls unless the corresponding compat_ system call is > > > implemented. > > > > Good point. > > > > > This makes sure that people adding system calls will design the API for > > > the new system call appropriately, rather than trying to implement > > > compat support as an afterthought and only then realising that they wish > > > the original had been done differently. We've seen examples of this > > > where it would have been _trivial_ to adjust the API slightly to make > > > compat syscalls a non-issue, but the developer just didn't _think_ about > > > it until the syscall was set in stone. > > > > > > This new system call seems to need compat_ support but lacks it, so I > > > would suggest you shouldn't merge it just yet. > > > > OK, thanks. > > urgh, new system calls... wonder if they fit in the ARM ABI... Looks > fine. What's the ARM ABI? > Are there any other new syscalls sitting around in -mm ? Yes, the AIO listio additions: From: Bharata B Rao <[EMAIL PROTECTED]> This patch provides POSIX listio support by means of a new system call. long lio_submit(aio_context_t ctx_id, int mode, long nr, struct iocb __user * __user *iocbpp, struct sigevent __user *event) This system call is similar to the io_submit() system call, but takes two more arguments. 'mode' argument can be LIO_WAIT or LIO_NOWAIT. 'event' argument specifies the signal notification mechanism. This patch is built on support provided by the aio signal notification patch by Sebastien. The following two structures together provide the support for grouping iocbs belonging to a list (lio). struct aio_notify { struct task_struct *target; __u16 signo; __u16 notify; sigval_tvalue; struct sigqueue *sigq; }; struct lio_event { atomic_tlio_users; struct aio_notify lio_notify; }; A single lio_event struct is maintained for the list of iocbs. lio_users holds the number of requests attached to this lio and lio_notify has the necessary information for generating completion notification signal. If the mode is LIO_WAIT, the event argument is ignored and the system call waits until all the requests of the lio are completed. If the mode is LIO_NOWAIT, the system call returns immediately after submitting the io requests and may optionally notify the process on list io completion depending on the event argument. Signed-off-by: S_bastien Dugu_ <[EMAIL PROTECTED]> Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> Signed-off-by: Bharata B Rao <[EMAIL PROTECTED]> Cc: Bharata B Rao <[EMAIL PROTECTED]> Cc: Christoph Hellwig <[EMAIL PROTECTED]> Cc: Suparna Bhattacharya <[EMAIL PROTECTED]> Cc: Zach Brown <[EMAIL PROTECTED]> Cc: Oleg Nesterov <[EMAIL PROTECTED]> Cc: Badari Pulavarty <[EMAIL PROTECTED]> Cc: Benjamin LaHaise <[EMAIL PROTECTED]> Cc: Jean Pierre Dion <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- arch/i386/kernel/syscall_table.S |1 arch/x86_64/ia32/ia32entry.S |4 fs/aio.c | 188 + fs/compat.c | 119 +++--- include/asm-i386/unistd.h|3 include/asm-x86_64/unistd.h |4 include/linux/aio.h | 14 +- include/linux/aio_abi.h |5 include/linux/syscalls.h |2 9 files changed, 295 insertions(+), 45 deletions(-) diff -puN arch/i386/kernel/syscall_table.S~add-listio-syscall-support arch/i386/kernel/syscall_table.S --- a/arch/i386/kernel/syscall_table.S~add-listio-syscall-support +++ a/arch/i386/kernel/syscall_table.S @@ -319,3 +319,4 @@ ENTRY(sys_call_table) .long sys_move_pages .long sys_getcpu .long sys_epoll_pwait + .long sys_lio_submit/* 320 */ diff -puN arch/x86_64/ia32/ia32entry.S~add-listio-syscall-support arch/x86_64/ia32/ia32entry.S --- a/arch/x86_64/ia32/ia32entry.S~add-listio-syscall-support +++ a/arch/x86_64/ia32/ia32entry.S @@ -726,8 +726,10 @@ ia32_sys_call_table: .quad compat_sys_get_robust_list .quad sys_splice .quad sys_sync_file_range - .quad sys_tee + .quad sys_tee /* 315 */ .quad compat_sys_vmsplice .quad compat_sys_move_pages
Re: -mm merge plans for 2.6.21
On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: > > I would strongly recommend that in the general case, you don't merge new > > system calls unless the corresponding compat_ system call is > > implemented. > > Good point. It's a _damn_ good point, but I see we went ahead and merged sys_epoll_pwait without it anyway -- despite the fact that it's include/linux/eventpoll.h which contains the example of why we should think first :) I think I even threw together an untested implementation of compat_sys_epoll_pwait() at one point to assist with that task, but it didn't seem to help much. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 9 Feb 2007 19:37:53 + Alan <[EMAIL PROTECTED]> wrote: > Please just push the EDAC K8 stuff. OK. > Andi will say "no" from now until the > end of time, but end users want it, distributions want it, and Andi is > not the EDAC maintainer so should consider himself overruled on what > isn't a technical issue but a personal political viewpoint. I'll just tell him I sent it by accident. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 2007-02-09 at 21:49 +, Russell King wrote: > urgh, new system calls... wonder if they fit in the ARM ABI... Looks > fine. Can you elucidate on _what_ you just checked for? There was something about alignment of 64-bit arguments to syscalls which affects MIPS and/or ARM which I can't quite remember-- something about putting it them arguments in either an even-numbered or odd-numbered position to make it work nicely. Is that actually written anywhere, and does anyone bother to check? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, Feb 09, 2007 at 01:45:16PM -0800, Andrew Morton wrote: > On Fri, 09 Feb 2007 17:35:35 + > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > > lutimesat-simplify-utime2.patch > > > lutimesat-extend-do_utimes-with-flags.patch > > > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > > > > > Do we want this? Ulrich says so. Will merge, I guess. > > > > I would strongly recommend that in the general case, you don't merge new > > system calls unless the corresponding compat_ system call is > > implemented. > > Good point. > > > This makes sure that people adding system calls will design the API for > > the new system call appropriately, rather than trying to implement > > compat support as an afterthought and only then realising that they wish > > the original had been done differently. We've seen examples of this > > where it would have been _trivial_ to adjust the API slightly to make > > compat syscalls a non-issue, but the developer just didn't _think_ about > > it until the syscall was set in stone. > > > > This new system call seems to need compat_ support but lacks it, so I > > would suggest you shouldn't merge it just yet. > > OK, thanks. urgh, new system calls... wonder if they fit in the ARM ABI... Looks fine. Are there any other new syscalls sitting around in -mm ? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 09 Feb 2007 17:35:35 + David Woodhouse <[EMAIL PROTECTED]> wrote: > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > lutimesat-simplify-utime2.patch > > lutimesat-extend-do_utimes-with-flags.patch > > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > > > Do we want this? Ulrich says so. Will merge, I guess. > > I would strongly recommend that in the general case, you don't merge new > system calls unless the corresponding compat_ system call is > implemented. Good point. > This makes sure that people adding system calls will design the API for > the new system call appropriately, rather than trying to implement > compat support as an afterthought and only then realising that they wish > the original had been done differently. We've seen examples of this > where it would have been _trivial_ to adjust the API slightly to make > compat syscalls a non-issue, but the developer just didn't _think_ about > it until the syscall was set in stone. > > This new system call seems to need compat_ support but lacks it, so I > would suggest you shouldn't merge it just yet. OK, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Please just push the EDAC K8 stuff. Andi will say "no" from now until the end of time, but end users want it, distributions want it, and Andi is not the EDAC maintainer so should consider himself overruled on what isn't a technical issue but a personal political viewpoint. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > lutimesat-simplify-utime2.patch > lutimesat-extend-do_utimes-with-flags.patch > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > Do we want this? Ulrich says so. Will merge, I guess. I would strongly recommend that in the general case, you don't merge new system calls unless the corresponding compat_ system call is implemented. This makes sure that people adding system calls will design the API for the new system call appropriately, rather than trying to implement compat support as an afterthought and only then realising that they wish the original had been done differently. We've seen examples of this where it would have been _trivial_ to adjust the API slightly to make compat syscalls a non-issue, but the developer just didn't _think_ about it until the syscall was set in stone. This new system call seems to need compat_ support but lacks it, so I would suggest you shouldn't merge it just yet. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Thu, 2007-02-08 at 15:44 -0800, Andrew Morton wrote: > Yeah, this seems to work. > > +#define emit_old_interrupt_name(old, new)\ > +static inline unsigned __deprecated emit_old_interrupt_name##old(void) > \ > +{\ > + return (new); \ > +} > + > +emit_old_interrupt_name(SA_INTERRUPT, IRQF_DISABLED) > +#define SA_INTERRUPT emit_old_interrupt_nameSA_INTERRUPT() /me cringes, but if it makes people happy, so be it. Please update the expiry date of this evil source of eye cancer. tglx diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 2dc5e5d..125a1c6 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -199,7 +199,7 @@ Who:Nick Piggin <[EMAIL PROTECTED]> --- What: Interrupt only SA_* flags -When: Januar 2007 +When: August 2007 Why: The interrupt related SA_* flags are replaced by IRQF_* to move them out of the signal namespace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Quoting Arjan van de Ven <[EMAIL PROTECTED]>: > > > > > As long as nobody takes the address of them (which wouldn't compile today > > anyway) then the compiler should be able to not allocate store for these. > > That they're const might help too. > > are you really sure? I've run some tests, and the compiler seems to do the right thing -I must admit, that I trusted the compiler to do it blindly on my first attempt :)- , see below: > cat flag.h static const int __attribute__((__deprecated__)) SA_INTERRUPT = 0x123456; > cat use_flag.c #include #include "flag.h" int main() { int flags = SA_INTERRUPT; printf("%d", flags); } > cat dont_use_flag.c #include #include "flag.h" int main() { int flags = 0; printf("%d", flags); } > gcc --version gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3) > for i in *use_flag.c; do gcc -o $(echo $i | sed 's/.c//') -O2 -g $i; done use_flag.c: In function 'main': use_flag.c:6: warning: 'SA_INTERRUPT' is deprecated (declared at flag.h:1) > size *use_flag textdata bss dec hex filename 897 260 41161 489 dont_use_flag 897 260 41161 489 use_flag # The relevant parts of the compiled code, see how the flag is replaced with # the const value in the code. It does not result in a code size increment. > objdump -d {dont_,}use_flag | grep -A11 '' 080483b0 : 80483b0: 8d 4c 24 04 lea0x4(%esp),%ecx 80483b4: 83 e4 f0and$0xfff0,%esp 80483b7: ff 71 fcpushl 0xfffc(%ecx) 80483ba: 31 c0 xor%eax,%eax 80483bc: 55 push %ebp 80483bd: 89 e5 mov%esp,%ebp 80483bf: 51 push %ecx 80483c0: 83 ec 14sub$0x14,%esp 80483c3: 89 44 24 04 mov%eax,0x4(%esp) 80483c7: c7 04 24 b8 84 04 08movl $0x80484b8,(%esp) 80483ce: e8 05 ff ff ff call 80482d8 <[EMAIL PROTECTED]> -- 080483b0 : 80483b0: 8d 4c 24 04 lea0x4(%esp),%ecx 80483b4: 83 e4 f0and$0xfff0,%esp 80483b7: ff 71 fcpushl 0xfffc(%ecx) 80483ba: b8 56 34 12 00 mov$0x123456,%eax 80483bf: 55 push %ebp 80483c0: 89 e5 mov%esp,%ebp 80483c2: 51 push %ecx 80483c3: 83 ec 14sub$0x14,%esp 80483c6: 89 44 24 04 mov%eax,0x4(%esp) 80483ca: c7 04 24 b8 84 04 08movl $0x80484b8,(%esp) 80483d1: e8 02 ff ff ff call 80482d8 <[EMAIL PROTECTED]> With 3.4.3 == $ gcc --version gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) $ size {dont_,}use_flag textdata bss dec hex filename 851 256 4 457 dont_use_flag 855 256 41115 45b use_flag [EMAIL PROTECTED] ~]$ objdump -d {dont_,}use_flag | grep -A11 '' 08048368 : 8048368: 55 push %ebp 8048369: 89 e5 mov%esp,%ebp 804836b: 83 ec 08sub$0x8,%esp 804836e: 83 e4 f0and$0xfff0,%esp 8048371: 83 ec 18sub$0x18,%esp 8048374: 6a 00 push $0x0 8048376: 68 64 84 04 08 push $0x8048464 804837b: e8 30 ff ff ff call 80482b0 <[EMAIL PROTECTED]> -- 08048368 : 8048368: 55 push %ebp 8048369: 89 e5 mov%esp,%ebp 804836b: 83 ec 08sub$0x8,%esp 804836e: 83 e4 f0and$0xfff0,%esp 8048371: 83 ec 18sub$0x18,%esp 8048374: 68 56 34 12 00 push $0x123456 8048379: 68 68 84 04 08 push $0x8048468 804837e: e8 2d ff ff ff call 80482b0 <[EMAIL PROTECTED]> So I'd say that both in 3.4.3 and 4.1.1, no extra space is needed for the "const static int" flag. Regards, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Andrew Morton wrote: On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote: Has it? I don't think I've ever observed any benefits from it and I don't think anyone has ever got down and worked out what its drawbacks might be, and seen if they can be demonstrated in practice. Who should get down? It seems no serious kernel developer cares enough to get to it. It's just a desktop feature you know - no big iron - uninteresting. Why keep it in -mm for so long? I'm waiting to be shown that its benefits exceed its costs. Sometimes that's hard. Swap prefetch and those mystic _costs_. But nobody hasn't communicated loud and clear what those costs are. I imagine it must be really hard to fight to something you don't even exists. Or prove that you are better than somebody you have never seen or heard of. Please somebody qualified, take the time, dig that code, and show us those costs. With details. So Con can make the code even better and included in mainline or drop altogether if it's really bad and move on to other endeavours. With best, Lenar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote: > Hello, > > Andrew Morton wrote: > > sched-add-above-background-load-function.patch > > mm-implement-swap-prefetching.patch > > mm-implement-swap-prefetching-vs-zvc-stuff.patch > > mm-implement-swap-prefetching-vs-zvc-stuff-2.patch > > mm-implement-swap-prefetching-use-ctl_unnumbered.patch > > swap_prefetch-vs-zoned-counters.patch > > add-include-linux-freezerh-and-move-definitions-from-prefetch.patch > > zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable-swap_prefetch.patch > > reduce-max_nr_zones-swap_prefetch-remove-incorrect-use-of-zone_highmem.patch > > sched-cleanup-remove-task_t-convert-to-struct-task_struct-prefetch.patch > > numa-add-zone_to_nid-function-swap_prefetch.patch > > remove-uses-of-kmem_cache_t-from-mm-and-include-linux-slabh-prefetch.patch > > > > Hold. > Why hold? > > It's been shown this patchset really helps desktop users. Has it? I don't think I've ever observed any benefits from it and I don't think anyone has ever got down and worked out what its drawbacks might be, and seen if they can be demonstrated in practice. Plenty of people replied with positive reviews when it was posted earlier. I'd expect that you'd have a fair bit of ram, so you're less likely to observe any benefit, as you wouldnt be digging into swap as often as those on lesser systems. http://lkml.org/lkml/2006/3/23/25 I also have vague memories of some serious-sounding review comments about the code from Nick. http://lkml.org/lkml/2006/3/23/55 Could that be it? Maybe repoll Con on those. > Why keep it in -mm for so long? I'm waiting to be shown that its benefits exceed its costs. Sometimes that's hard. Con's patchset is used pretty widely now, with many distro's (Arch, Mandriva, PCLinuxOS among others) providing prebuilt kernels and nobody has reported any drawbacks. I don't think anyone in -mm has reported any either. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
> > As long as nobody takes the address of them (which wouldn't compile today > anyway) then the compiler should be able to not allocate store for these. > That they're const might help too. are you really sure? > > > why not just bite the bullet? > > removing version.h also broke the same all external modules, and they > > got fixed in days.. no big deal. kernel api change all the time, this > > one has been around in "double mode" quite some time... > > Pretty much every driver in the world will want these symbols. I expect > we'll help some people by doing this, and the cost to us is very small. well the same people had to change for the request_irq prototype change etc etc. I suppose they'll all get fixed if some distro does this cleanup anyway... otherwise no amount of deprecation will get things changed; unless the compile actually breaks nobody will pay attention. Also quite a few external drivers that are aiming for mainline inclusion should already be using the new settings for a while anyway... Another option is to back out the change again totally; having 2 constants for the same thing is just a bad idea, and old users will keep sneaking in. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Feb 9 2007 14:04, Andi Kleen wrote: >Andrew Morton <[EMAIL PROTECTED]> writes: >> >> As long as nobody takes the address of them (which wouldn't compile today >> anyway) then the compiler should be able to not allocate store for these. > >This would only work for unit-at-a-time compilers (if it works at all, >i'm not sure), but not older 3.x compilers > >> That they're const might help too. > >Don't think it does. GCC 4.1 optimizes both Andrew's and Frederik Deweerdt's ideas perfectly out. Even if the const was not there in Frederik's example, gcc seems throw it out with -O2 (judging by `nm` output) since it is 1. static 2. unused. Gcc even gives out a warning that the item is unused when not marked with const. Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Andrew Morton <[EMAIL PROTECTED]> writes: > > As long as nobody takes the address of them (which wouldn't compile today > anyway) then the compiler should be able to not allocate store for these. This would only work for unit-at-a-time compilers (if it works at all, i'm not sure), but not older 3.x compilers > That they're const might help too. Don't think it does. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 09 Feb 2007 12:24:33 +0100 Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; > > +static const int __deprecated SA_SHIRQ = IRQF_SHARED; > > +static const int __deprecated SA_PROBEIRQ = IRQF_PROBE_SHARED; > > +static const int __deprecated SA_PERCPU = IRQF_PERCPU; > > + > > +static const int __deprecated SA_TRIGGER_LOW = IRQF_TRIGGER_LOW; > > +static const int __deprecated SA_TRIGGER_HIGH = IRQF_TRIGGER_HIGH; > > +static const int __deprecated SA_TRIGGER_FALLING = IRQF_TRIGGER_FALLING; > > +static const int __deprecated SA_TRIGGER_RISING = IRQF_TRIGGER_RISING; > > +static const int __deprecated SA_TRIGGER_MASK = IRQF_TRIGGER_MASK; > > this will include these in every .o file for which the .c file includes > the header. NOT GOOD(tm) As long as nobody takes the address of them (which wouldn't compile today anyway) then the compiler should be able to not allocate store for these. That they're const might help too. > why not just bite the bullet? > removing version.h also broke the same all external modules, and they > got fixed in days.. no big deal. kernel api change all the time, this > one has been around in "double mode" quite some time... Pretty much every driver in the world will want these symbols. I expect we'll help some people by doing this, and the cost to us is very small. Plus we're getting a bad reputation out there for breaking stuff and screwing people around, which isn't good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; > +static const int __deprecated SA_SHIRQ = IRQF_SHARED; > +static const int __deprecated SA_PROBEIRQ = IRQF_PROBE_SHARED; > +static const int __deprecated SA_PERCPU = IRQF_PERCPU; > + > +static const int __deprecated SA_TRIGGER_LOW = IRQF_TRIGGER_LOW; > +static const int __deprecated SA_TRIGGER_HIGH = IRQF_TRIGGER_HIGH; > +static const int __deprecated SA_TRIGGER_FALLING = IRQF_TRIGGER_FALLING; > +static const int __deprecated SA_TRIGGER_RISING = IRQF_TRIGGER_RISING; > +static const int __deprecated SA_TRIGGER_MASK = IRQF_TRIGGER_MASK; this will include these in every .o file for which the .c file includes the header. NOT GOOD(tm) why not just bite the bullet? removing version.h also broke the same all external modules, and they got fixed in days.. no big deal. kernel api change all the time, this one has been around in "double mode" quite some time... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, Feb 09, 2007 at 12:29:06AM +0100, Jan Engelhardt wrote: > > On Feb 8 2007 15:07, Andrew Morton wrote: > > >scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch > >scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch > >scheduled-removal-of-sa_xxx-interrupt-flags.patch > >scheduled-removal-of-sa_xxx-interrupt-flags-ata-fix.patch > > > > This removes SA_INTERRUPT and friends, so 1000 external drivers won't > > compile any more. I think I'd prefer to find a way to get usage of SA_* to > > spit a deprecated warning. > > Here's an idea: > > #define SA_INTERRUPT sa_interrupt_with_warning() > static inline int sa_interrupt_with_warning(void) { > if(more_or_less_often) > printk(fat_warning); > return 0x123456; /* whatever numerical value it is */ > } > I'd say that we want to warn the developper, not the user, isn't it? The attached patch marks the variables as __deprecated, and re-schedules the removal for January 2008. Regards, Frederik diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index b7c642c..4a5aad3 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -308,3 +308,12 @@ Why: OSS drivers with ALSA replacements Who: Adrian Bunk <[EMAIL PROTECTED]> --- + +What: Interrupt only SA_* flags +When: January 2008 +Why: The interrupt related SA_* flags are replaced by IRQF_* to move them + out of the signal namespace. + +Who: Frederik Deweerdt <[EMAIL PROTECTED]> + +--- diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index e66b458..472f2d2 100644 --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -52,6 +52,25 @@ #define IRQF_PERCPU0x0400 #define IRQF_NOBALANCING 0x0800 +/* + * Migration helpers. Scheduled for removal in 1/2008 + * SA_* flags are now deprecated, leaving time for out-of-the-tree drivers + * to catch up. + * + * Do not use for new code ! + */ +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; +static const int __deprecated SA_SHIRQ = IRQF_SHARED; +static const int __deprecated SA_PROBEIRQ = IRQF_PROBE_SHARED; +static const int __deprecated SA_PERCPU = IRQF_PERCPU; + +static const int __deprecated SA_TRIGGER_LOW = IRQF_TRIGGER_LOW; +static const int __deprecated SA_TRIGGER_HIGH = IRQF_TRIGGER_HIGH; +static const int __deprecated SA_TRIGGER_FALLING = IRQF_TRIGGER_FALLING; +static const int __deprecated SA_TRIGGER_RISING = IRQF_TRIGGER_RISING; +static const int __deprecated SA_TRIGGER_MASK = IRQF_TRIGGER_MASK; + typedef irqreturn_t (*irq_handler_t)(int, void *); struct irqaction { - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote: > Hello, > > Andrew Morton wrote: > > sched-add-above-background-load-function.patch > > mm-implement-swap-prefetching.patch > > mm-implement-swap-prefetching-vs-zvc-stuff.patch > > mm-implement-swap-prefetching-vs-zvc-stuff-2.patch > > mm-implement-swap-prefetching-use-ctl_unnumbered.patch > > swap_prefetch-vs-zoned-counters.patch > > add-include-linux-freezerh-and-move-definitions-from-prefetch.patch > > zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable-swap_prefetch.patch > > reduce-max_nr_zones-swap_prefetch-remove-incorrect-use-of-zone_highmem.patch > > sched-cleanup-remove-task_t-convert-to-struct-task_struct-prefetch.patch > > numa-add-zone_to_nid-function-swap_prefetch.patch > > remove-uses-of-kmem_cache_t-from-mm-and-include-linux-slabh-prefetch.patch > > > > Hold. > Why hold? > > It's been shown this patchset really helps desktop users. Has it? I don't think I've ever observed any benefits from it and I don't think anyone has ever got down and worked out what its drawbacks might be, and seen if they can be demonstrated in practice. I also have vague memories of some serious-sounding review comments about the code from Nick. > Why keep it in -mm for so long? I'm waiting to be shown that its benefits exceed its costs. Sometimes that's hard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 9 Feb 2007 01:05:57 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 9 Feb 2007 09:26:11 +0100 Sébastien Dugué <[EMAIL PROTECTED]> wrote: > > > On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote: > > > > > Andrew, > > > > > > On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch > > > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine-gfs2-fix.patch > > > > fsaio-rename-__lock_page-to-lock_page_blocking.patch > > > > fsaio-interfaces-to-initialize-and-to-test-a-wait-bit-key.patch > > > > fsaio-add-a-default-io-wait-bit-field-in-task-struct.patch > > > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio.patch > > > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix.patch > > > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix-sparse-fix.patch > > > > fsaio-enable-asynchronous-wait-page-and-lock-page.patch > > > > fsaio-filesystem-aio-read.patch > > > > fsaio-aio-o_sync-filesystem-write.patch > > > > > > > > Will wait to see what happens with febrils. > > > > > > > > aio-is-unlikely.patch > > > > > > > > Will merge. > > > > > > > > rework-compat_sys_io_submit.patch > > > > fix-aioh-includes.patch > > > > fix-access_ok-checks.patch > > > > make-good_sigevent-non-static.patch > > > > make-good_sigevent-non-static-fix.patch > > > > make-__sigqueue_free-and.patch > > > > aio-completion-signal-notification.patch > > > > aio-completion-signal-notification-fix.patch > > > > aio-completion-signal-notification-fixes-and-cleanups.patch > > > > aio-completion-signal-notification-small-cleanup.patch > > > > add-listio-syscall-support.patch > > > > > > > > I guess these are dependent upon fsaio. > > > > > > No. AIO completion signal notification patches and listio patch work > > > independently of fsaio patches. Just that for buffered AIO case, the > > > fsaio patches will make the behaviour truly asynchronous. > > > > > > Regards, > > > Bharata. > > > > I concur. > > > > But is the proposed listio implementation still relevant if we go and add > the async syscalls? I think the listio syscall could be emulated in userspace using async syscalls. Even more, the whole POSIX AIO functions could benefit from this, rendering aio.c obsolete. Sébastien. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
Hello, Andrew Morton wrote: sched-add-above-background-load-function.patch mm-implement-swap-prefetching.patch mm-implement-swap-prefetching-vs-zvc-stuff.patch mm-implement-swap-prefetching-vs-zvc-stuff-2.patch mm-implement-swap-prefetching-use-ctl_unnumbered.patch swap_prefetch-vs-zoned-counters.patch add-include-linux-freezerh-and-move-definitions-from-prefetch.patch zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable-swap_prefetch.patch reduce-max_nr_zones-swap_prefetch-remove-incorrect-use-of-zone_highmem.patch sched-cleanup-remove-task_t-convert-to-struct-task_struct-prefetch.patch numa-add-zone_to_nid-function-swap_prefetch.patch remove-uses-of-kmem_cache_t-from-mm-and-include-linux-slabh-prefetch.patch Hold. Why hold? It's been shown this patchset really helps desktop users. Why keep it in -mm for so long? L. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 9 Feb 2007 09:26:11 +0100 Sébastien Dugué <[EMAIL PROTECTED]> wrote: > On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote: > > > Andrew, > > > > On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch > > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine-gfs2-fix.patch > > > fsaio-rename-__lock_page-to-lock_page_blocking.patch > > > fsaio-interfaces-to-initialize-and-to-test-a-wait-bit-key.patch > > > fsaio-add-a-default-io-wait-bit-field-in-task-struct.patch > > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio.patch > > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix.patch > > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix-sparse-fix.patch > > > fsaio-enable-asynchronous-wait-page-and-lock-page.patch > > > fsaio-filesystem-aio-read.patch > > > fsaio-aio-o_sync-filesystem-write.patch > > > > > > Will wait to see what happens with febrils. > > > > > > aio-is-unlikely.patch > > > > > > Will merge. > > > > > > rework-compat_sys_io_submit.patch > > > fix-aioh-includes.patch > > > fix-access_ok-checks.patch > > > make-good_sigevent-non-static.patch > > > make-good_sigevent-non-static-fix.patch > > > make-__sigqueue_free-and.patch > > > aio-completion-signal-notification.patch > > > aio-completion-signal-notification-fix.patch > > > aio-completion-signal-notification-fixes-and-cleanups.patch > > > aio-completion-signal-notification-small-cleanup.patch > > > add-listio-syscall-support.patch > > > > > > I guess these are dependent upon fsaio. > > > > No. AIO completion signal notification patches and listio patch work > > independently of fsaio patches. Just that for buffered AIO case, the > > fsaio patches will make the behaviour truly asynchronous. > > > > Regards, > > Bharata. > > I concur. > But is the proposed listio implementation still relevant if we go and add the async syscalls? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.21
On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote: > Andrew, > > On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine-gfs2-fix.patch > > fsaio-rename-__lock_page-to-lock_page_blocking.patch > > fsaio-interfaces-to-initialize-and-to-test-a-wait-bit-key.patch > > fsaio-add-a-default-io-wait-bit-field-in-task-struct.patch > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio.patch > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix.patch > > fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio-fix-sparse-fix.patch > > fsaio-enable-asynchronous-wait-page-and-lock-page.patch > > fsaio-filesystem-aio-read.patch > > fsaio-aio-o_sync-filesystem-write.patch > > > > Will wait to see what happens with febrils. > > > > aio-is-unlikely.patch > > > > Will merge. > > > > rework-compat_sys_io_submit.patch > > fix-aioh-includes.patch > > fix-access_ok-checks.patch > > make-good_sigevent-non-static.patch > > make-good_sigevent-non-static-fix.patch > > make-__sigqueue_free-and.patch > > aio-completion-signal-notification.patch > > aio-completion-signal-notification-fix.patch > > aio-completion-signal-notification-fixes-and-cleanups.patch > > aio-completion-signal-notification-small-cleanup.patch > > add-listio-syscall-support.patch > > > > I guess these are dependent upon fsaio. > > No. AIO completion signal notification patches and listio patch work > independently of fsaio patches. Just that for buffered AIO case, the > fsaio patches will make the behaviour truly asynchronous. > > Regards, > Bharata. I concur. Thanks, Sébastien. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/