Re: 2.6.23-rc8-mm2 ACPI Battery Info in /sys but not /proc/acpi
On Fri, 2007-10-19 at 11:59 -0400, Chris Bandy wrote: > I had this same problem, but found that it was because I turned off the > newly deprecated CONFIG_ACPI_PROCFS. This was the problem. Thank you. What confused me was that *only* the battery information seemed to be missing. If all the ACPI info in /proc had been missing I would have suspected something like this right away. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.23-rc8-mm2 ACPI Battery Info in /sys but not /proc/acpi
On Fri, 2007-10-19 at 11:59 -0400, Chris Bandy wrote: I had this same problem, but found that it was because I turned off the newly deprecated CONFIG_ACPI_PROCFS. This was the problem. Thank you. What confused me was that *only* the battery information seemed to be missing. If all the ACPI info in /proc had been missing I would have suspected something like this right away. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [BUG] 2.6.23-rc8-mm2 - call trace at kernel/lockdep.c:2664
On Sat, 13 Oct 2007 11:51:25 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > Following call trace is seen will booting up the machine. Similar > call trace was reported for 2.6.23-rc3-mm1 at > http://lkml.org/lkml/2007/8/26/77 > > Mount-cache hash table entries: 512 > WARNING: at kernel/lockdep.c:2664 check_flags() > [] dump_trace+0x68/0x1d2 > [] show_trace_log_lvl+0x18/0x2c > [] show_trace+0xf/0x11 > [] dump_stack+0x12/0x14 > [] check_flags+0x92/0x145 > [] lock_acquire+0x2f/0x8a > [] _spin_lock+0x33/0x3e > [] ifind+0x16/0x7f > [] ilookup5_nowait+0x33/0x38 > [] sysfs_addrm_start+0x36/0x84 > [] create_dir+0x37/0x86 > [] sysfs_create_dir+0x2d/0x40 > [] kobject_add+0xe9/0x190 > [] kset_register+0x19/0x2e > [] mnt_init+0xe0/0x1be > [] vfs_caches_init+0x11e/0x12e > [] start_kernel+0x2ed/0x318 > === > irq event stamp: 1139108 > hardirqs last enabled at (1139108): [] > __mutex_lock_slowpath+0x24d/0x273 > hardirqs last disabled at (1139107): [] cpu_clock+0xd/0x4c > softirqs last enabled at (1138798): [] do_softirq+0x36/0x51 > softirqs last disabled at (1138793): [] do_softirq+0x36/0x51 > CPU: After generic identify, caps: bfebfbff 2010 > 0004e3bd 0001 > Were kprobes/jprobes in use? If so, 2.6.23-mm1's lockdep-annotate-kprobes-irq-fiddling.patch should help. - 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/
[BUG] 2.6.23-rc8-mm2 - call trace at kernel/lockdep.c:2664
Hi Andrew, Following call trace is seen will booting up the machine. Similar call trace was reported for 2.6.23-rc3-mm1 at http://lkml.org/lkml/2007/8/26/77 Mount-cache hash table entries: 512 WARNING: at kernel/lockdep.c:2664 check_flags() [] dump_trace+0x68/0x1d2 [] show_trace_log_lvl+0x18/0x2c [] show_trace+0xf/0x11 [] dump_stack+0x12/0x14 [] check_flags+0x92/0x145 [] lock_acquire+0x2f/0x8a [] _spin_lock+0x33/0x3e [] ifind+0x16/0x7f [] ilookup5_nowait+0x33/0x38 [] sysfs_addrm_start+0x36/0x84 [] create_dir+0x37/0x86 [] sysfs_create_dir+0x2d/0x40 [] kobject_add+0xe9/0x190 [] kset_register+0x19/0x2e [] mnt_init+0xe0/0x1be [] vfs_caches_init+0x11e/0x12e [] start_kernel+0x2ed/0x318 === irq event stamp: 1139108 hardirqs last enabled at (1139108): [] __mutex_lock_slowpath+0x24d/0x273 hardirqs last disabled at (1139107): [] cpu_clock+0xd/0x4c softirqs last enabled at (1138798): [] do_softirq+0x36/0x51 softirqs last disabled at (1138793): [] do_softirq+0x36/0x51 CPU: After generic identify, caps: bfebfbff 2010 0004e3bd 0001 -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Wed Oct 10 10:59:23 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=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" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y 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_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y # CONFIG_X86_PC is not set # 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=y # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set CONFIG_X86_CYCLONE_TIMER=y # 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_MPENTIUM4 is not set CONFIG_MCORE2=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_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORI
[BUG] 2.6.23-rc8-mm2 - call trace at kernel/lockdep.c:2664
Hi Andrew, Following call trace is seen will booting up the machine. Similar call trace was reported for 2.6.23-rc3-mm1 at http://lkml.org/lkml/2007/8/26/77 Mount-cache hash table entries: 512 WARNING: at kernel/lockdep.c:2664 check_flags() [c010612f] dump_trace+0x68/0x1d2 [c01062b1] show_trace_log_lvl+0x18/0x2c [c0106c23] show_trace+0xf/0x11 [c0106d33] dump_stack+0x12/0x14 [c01414ac] check_flags+0x92/0x145 [c0144426] lock_acquire+0x2f/0x8a [c0509771] _spin_lock+0x33/0x3e [c0180e2b] ifind+0x16/0x7f [c0180eff] ilookup5_nowait+0x33/0x38 [c01a793d] sysfs_addrm_start+0x36/0x84 [c01a7dc7] create_dir+0x37/0x86 [c01a7e43] sysfs_create_dir+0x2d/0x40 [c029ab5e] kobject_add+0xe9/0x190 [c029ac26] kset_register+0x19/0x2e [c07a58a7] mnt_init+0xe0/0x1be [c07a552a] vfs_caches_init+0x11e/0x12e [c07938e5] start_kernel+0x2ed/0x318 === irq event stamp: 1139108 hardirqs last enabled at (1139108): [c05085a4] __mutex_lock_slowpath+0x24d/0x273 hardirqs last disabled at (1139107): [c0124221] cpu_clock+0xd/0x4c softirqs last enabled at (1138798): [c012d2b5] do_softirq+0x36/0x51 softirqs last disabled at (1138793): [c012d2b5] do_softirq+0x36/0x51 CPU: After generic identify, caps: bfebfbff 2010 0004e3bd 0001 -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Wed Oct 10 10:59:23 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=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 # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y 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_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y # CONFIG_X86_PC is not set # 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=y # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set CONFIG_X86_CYCLONE_TIMER=y # 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_MPENTIUM4 is not set CONFIG_MCORE2=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_MVIAC7 is not set CONFIG_X86_GENERIC=y
Re: [BUG] 2.6.23-rc8-mm2 - call trace at kernel/lockdep.c:2664
On Sat, 13 Oct 2007 11:51:25 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, Following call trace is seen will booting up the machine. Similar call trace was reported for 2.6.23-rc3-mm1 at http://lkml.org/lkml/2007/8/26/77 Mount-cache hash table entries: 512 WARNING: at kernel/lockdep.c:2664 check_flags() [c010612f] dump_trace+0x68/0x1d2 [c01062b1] show_trace_log_lvl+0x18/0x2c [c0106c23] show_trace+0xf/0x11 [c0106d33] dump_stack+0x12/0x14 [c01414ac] check_flags+0x92/0x145 [c0144426] lock_acquire+0x2f/0x8a [c0509771] _spin_lock+0x33/0x3e [c0180e2b] ifind+0x16/0x7f [c0180eff] ilookup5_nowait+0x33/0x38 [c01a793d] sysfs_addrm_start+0x36/0x84 [c01a7dc7] create_dir+0x37/0x86 [c01a7e43] sysfs_create_dir+0x2d/0x40 [c029ab5e] kobject_add+0xe9/0x190 [c029ac26] kset_register+0x19/0x2e [c07a58a7] mnt_init+0xe0/0x1be [c07a552a] vfs_caches_init+0x11e/0x12e [c07938e5] start_kernel+0x2ed/0x318 === irq event stamp: 1139108 hardirqs last enabled at (1139108): [c05085a4] __mutex_lock_slowpath+0x24d/0x273 hardirqs last disabled at (1139107): [c0124221] cpu_clock+0xd/0x4c softirqs last enabled at (1138798): [c012d2b5] do_softirq+0x36/0x51 softirqs last disabled at (1138793): [c012d2b5] do_softirq+0x36/0x51 CPU: After generic identify, caps: bfebfbff 2010 0004e3bd 0001 Were kprobes/jprobes in use? If so, 2.6.23-mm1's lockdep-annotate-kprobes-irq-fiddling.patch should help. - 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: 2.6.23-rc8-mm2
On Thu, Sep 27, 2007 at 02:22:20AM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > > - The scheduler devel tree has been restored > > - The driver tree is presently busted, so I reverted it to the 2..23-rc8-mm1 > version. > > - It's now a nearly-32MB diff. Here's a nearly-useless bug report for ya: The -mm kernels between rc4-mm1 and rc8-mm1 have been locking up for me in X when run for about a day or so. The crash does not appear correlated with any particular action on my part - it seems just as likely to happen if I'm typing in a local editor or over an ssh session or using my web browser. The capslock light blinks, so it's probably generating a trace and it still responds to sysrq but no logs make it to disk. As my laptop generally doesn't stay put for a whole day, I haven't managed to capture any of these traces. System is a Thinkpad R51, here's the config. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Mon Oct 8 21:58:21 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=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" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y 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_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG 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_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # 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_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT=y # CONFIG_XEN is not set # CONFIG_VMI 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=y # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # 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_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y 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_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG
Re: 2.6.23-rc8-mm2
On Thu, Sep 27, 2007 at 02:22:20AM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ - The scheduler devel tree has been restored - The driver tree is presently busted, so I reverted it to the 2..23-rc8-mm1 version. - It's now a nearly-32MB diff. Here's a nearly-useless bug report for ya: The -mm kernels between rc4-mm1 and rc8-mm1 have been locking up for me in X when run for about a day or so. The crash does not appear correlated with any particular action on my part - it seems just as likely to happen if I'm typing in a local editor or over an ssh session or using my web browser. The capslock light blinks, so it's probably generating a trace and it still responds to sysrq but no logs make it to disk. As my laptop generally doesn't stay put for a whole day, I haven't managed to capture any of these traces. System is a Thinkpad R51, here's the config. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Mon Oct 8 21:58:21 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=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 # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y 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_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG 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_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # 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_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT=y # CONFIG_XEN is not set # CONFIG_VMI 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=y # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # 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_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y 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_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y
Re: 2.6.23-rc8-mm2
On 9/29/07, Greg KH <[EMAIL PROTECTED]> wrote: > On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > > Hi, > > The kernel report warnings about sysfs filename duplicate under > > rc8-mm1 and rc8-mm2. > > 1. > > cut > > NET: Registered protocol family 16 > > ACPI: bus type pci registered > > PCI: PCI BIOS revision 2.10 entry at 0xfb93e, last bus=3 > > PCI: Using configuration type 1 > > Setting up standard PCI resources > > sysfs: duplicate filename 'usbcore' can not be created > > WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 > > [] dump_stack+0x12/0x20 > > [] sysfs_add_one+0xa0/0xe0 > > [] create_dir+0x48/0xb0 > > [] sysfs_create_dir+0x29/0x50 > > [] create_dir+0x1b/0x50 > > [] kobject_add+0x46/0x150 > > [] kernel_param_sysfs_setup+0x50/0xb0 > > [] param_sysfs_builtin+0xee/0x130 > > [] param_sysfs_init+0x24/0x60 > > [] do_initcalls+0x46/0x1e0 > > [] kernel_init+0x62/0xb0 > > [] kernel_thread_helper+0x7/0x14 > > === > > kobject_add failed for usbcore with -EEXIST, don't try to register > > things with the same name in the same directory. > > That is very wierd, do you have both USB built in and as a module > somehow? > > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 > > [] dump_stack+0x12/0x20 > > [] kobject_add+0xf6/0x150 > > [] kernel_param_sysfs_setup+0x50/0xb0 > > [] param_sysfs_builtin+0xee/0x130 > > [] param_sysfs_init+0x24/0x60 > > [] do_initcalls+0x46/0x1e0 > > [] kernel_init+0x62/0xb0 > > [] kernel_thread_helper+0x7/0x14 > > === > > Module 'usbcore' failed to be added to sysfs, error number -17 > > I think I need to clean up the double stack trace here, that's reall not > needed :) > Hi, I debugged the problem, found that it is a bug of kernel/params.c, I will send a patch later to fix it. Regards dave - 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: 2.6.23-rc8-mm2
On 9/29/07, Greg KH [EMAIL PROTECTED] wrote: On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: Hi, The kernel report warnings about sysfs filename duplicate under rc8-mm1 and rc8-mm2. 1. cut NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb93e, last bus=3 PCI: Using configuration type 1 Setting up standard PCI resources sysfs: duplicate filename 'usbcore' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() [c010528f] dump_trace+0x1bf/0x1d0 [c0105358] show_trace_log_lvl+0x18/0x30 [c010537f] show_trace+0xf/0x20 [c01054a2] dump_stack+0x12/0x20 [c01c6680] sysfs_add_one+0xa0/0xe0 [c01c69e8] create_dir+0x48/0xb0 [c01c6a99] sysfs_create_dir+0x29/0x50 [c02501eb] create_dir+0x1b/0x50 [c02504b6] kobject_add+0x46/0x150 [c05a38a0] kernel_param_sysfs_setup+0x50/0xb0 [c05a39ee] param_sysfs_builtin+0xee/0x130 [c05a3a54] param_sysfs_init+0x24/0x60 [c0592866] do_initcalls+0x46/0x1e0 [c0592aa2] kernel_init+0x62/0xb0 [c0104fb3] kernel_thread_helper+0x7/0x14 === kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory. That is very wierd, do you have both USB built in and as a module somehow? [c010528f] dump_trace+0x1bf/0x1d0 [c0105358] show_trace_log_lvl+0x18/0x30 [c010537f] show_trace+0xf/0x20 [c01054a2] dump_stack+0x12/0x20 [c0250566] kobject_add+0xf6/0x150 [c05a38a0] kernel_param_sysfs_setup+0x50/0xb0 [c05a39ee] param_sysfs_builtin+0xee/0x130 [c05a3a54] param_sysfs_init+0x24/0x60 [c0592866] do_initcalls+0x46/0x1e0 [c0592aa2] kernel_init+0x62/0xb0 [c0104fb3] kernel_thread_helper+0x7/0x14 === Module 'usbcore' failed to be added to sysfs, error number -17 I think I need to clean up the double stack trace here, that's reall not needed :) Hi, I debugged the problem, found that it is a bug of kernel/params.c, I will send a patch later to fix it. Regards dave - 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 1/2] [NetLabel] Introduce a new kernel configuration API for NetLabel - Repost - Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
From: Paul Moore <[EMAIL PROTECTED]>
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
include/net/netlabel.h | 47 --
net/ipv4/cipso_ipv4.c |4 -
net/netlabel/netlabel_cipso_v4.c |2
net/netlabel/netlabel_cipso_v4.h |3 +
net/netlabel/netlabel_domainhash.h |1
net/netlabel/netlabel_kapi.c | 174
6 files changed, 222 insertions(+), 9 deletions(-)
diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
#include
#include
+struct cipso_v4_doi;
+
/*
* NetLabel - A management interface for maintaining network packet label
*mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
};
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
/* LSM security attributes */
struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct
netlbl_lsm_secattr *secattr)
#ifdef CONFIG_NETLABEL
/*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+ const char *domain,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
* LSM security attribute operations
*/
int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
int netlbl_cache_add(const struct sk_buff *skb,
const struct netlbl_lsm_secattr *secattr);
#else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+ struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
static inline int netlbl_secattr_catmap_walk(
struct netlbl_lsm_secattr_catmap *catmap,
u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ab56a05..714461c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -557,8 +557,8 @@ int cipso_v4_doi_remove(u32 doi,
spin_unlock(_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, _def->dom_list, list)
if (dom_iter->valid)
- netlbl_domhsh_remove(dom_iter->domain,
-audit_info);
+ netlbl_cfg_map_del(dom_iter->domain,
+ audit_info);
cipso_v4_cache_invalidate();
rcu_read_unlock();
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index c060e3f..07f7fd4 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
* safely.
*
*/
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
{
struct cipso_v4_doi *ptr;
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
/* NetLabel protocol functions */
int netlbl_cipsov4_genl_init(void);
+/* Free the memory associated with a CIPSOv4 DOI definition */
+void
[PATCH 0/2] Repost - Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
I am reposting yesterday's Version 5 patch set because I know that it didn't get everywhere it was supposed to. I have broken the Smack patch into the netlabel changes from Paul Moore (1/2) and the Smack LSM (2/2), at Paul's kind suggestion. The smackfs symlinks have proven too contentious. I have removed the facility. Al and Alan are correct that the rich set of mount options currently available can handle any of the use cases I was looking at without excessive difficulty. I think that is the last of the major issues. I'm sure that if there are more y'all will let me know. Thank you. - 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 0/2] Repost - Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
I am reposting yesterday's Version 5 patch set because I know that it didn't get everywhere it was supposed to. I have broken the Smack patch into the netlabel changes from Paul Moore (1/2) and the Smack LSM (2/2), at Paul's kind suggestion. The smackfs symlinks have proven too contentious. I have removed the facility. Al and Alan are correct that the rich set of mount options currently available can handle any of the use cases I was looking at without excessive difficulty. I think that is the last of the major issues. I'm sure that if there are more y'all will let me know. Thank you. - 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 1/2] [NetLabel] Introduce a new kernel configuration API for NetLabel - Repost - Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
From: Paul Moore [EMAIL PROTECTED]
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
include/net/netlabel.h | 47 --
net/ipv4/cipso_ipv4.c |4 -
net/netlabel/netlabel_cipso_v4.c |2
net/netlabel/netlabel_cipso_v4.h |3 +
net/netlabel/netlabel_domainhash.h |1
net/netlabel/netlabel_kapi.c | 174
6 files changed, 222 insertions(+), 9 deletions(-)
diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
#include net/netlink.h
#include asm/atomic.h
+struct cipso_v4_doi;
+
/*
* NetLabel - A management interface for maintaining network packet label
*mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
};
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
/* LSM security attributes */
struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct
netlbl_lsm_secattr *secattr)
#ifdef CONFIG_NETLABEL
/*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+ const char *domain,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
* LSM security attribute operations
*/
int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
int netlbl_cache_add(const struct sk_buff *skb,
const struct netlbl_lsm_secattr *secattr);
#else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+ struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
static inline int netlbl_secattr_catmap_walk(
struct netlbl_lsm_secattr_catmap *catmap,
u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ab56a05..714461c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -557,8 +557,8 @@ int cipso_v4_doi_remove(u32 doi,
spin_unlock(cipso_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
- netlbl_domhsh_remove(dom_iter-domain,
-audit_info);
+ netlbl_cfg_map_del(dom_iter-domain,
+ audit_info);
cipso_v4_cache_invalidate();
rcu_read_unlock();
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index c060e3f..07f7fd4 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
* safely.
*
*/
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
{
struct cipso_v4_doi *ptr;
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
/* NetLabel protocol functions */
int netlbl_cipsov4_genl_init(void);
+/* Free the memory associated with a CIPSOv4 DOI
[PATCH 0/2] Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
I have broken the Smack patch into the netlabel changes from Paul Moore (1/2) and the Smack LSM (2/2), at Paul's kind suggestion. The smackfs symlinks have proven too contentious. I have removed the facility. Al and Alan are correct that the rich set of mount options currently available can handle any of the use cases I was looking at without excessive difficulty. I think that is the last of the major issues. I'm sure that if there are more y'all will let me know. Thank you. - 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 1/2] [NetLabel] Introduce a new kernel configuration API for NetLabel - Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
From: Paul Moore <[EMAIL PROTECTED]>
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
Signed-off-by: Casey Schaufler <[EMAIL PROTECTED]>
---
include/net/netlabel.h | 47 --
net/ipv4/cipso_ipv4.c |4 -
net/netlabel/netlabel_cipso_v4.c |2
net/netlabel/netlabel_cipso_v4.h |3 +
net/netlabel/netlabel_domainhash.h |1
net/netlabel/netlabel_kapi.c | 174
6 files changed, 222 insertions(+), 9 deletions(-)
diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
#include
#include
+struct cipso_v4_doi;
+
/*
* NetLabel - A management interface for maintaining network packet label
*mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
};
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
/* LSM security attributes */
struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct
netlbl_lsm_secattr *secattr)
#ifdef CONFIG_NETLABEL
/*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+ const char *domain,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
* LSM security attribute operations
*/
int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
int netlbl_cache_add(const struct sk_buff *skb,
const struct netlbl_lsm_secattr *secattr);
#else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+ struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
static inline int netlbl_secattr_catmap_walk(
struct netlbl_lsm_secattr_catmap *catmap,
u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ab56a05..714461c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -557,8 +557,8 @@ int cipso_v4_doi_remove(u32 doi,
spin_unlock(_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, _def->dom_list, list)
if (dom_iter->valid)
- netlbl_domhsh_remove(dom_iter->domain,
-audit_info);
+ netlbl_cfg_map_del(dom_iter->domain,
+ audit_info);
cipso_v4_cache_invalidate();
rcu_read_unlock();
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index c060e3f..07f7fd4 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
* safely.
*
*/
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
{
struct cipso_v4_doi *ptr;
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
/* NetLabel protocol functions */
int netlbl_cipsov4_genl_init(void);
+/* Free the memory
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Don Mullis wrote: > That patch boots without complaint as well. > > BTW, the earlier failure messages did not make it > into /var/log/messages, only the dmesg buffer. > This is with standard Ubuntu Gutsy logging levels. Super, thanks for retesting! -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
That patch boots without complaint as well.
BTW, the earlier failure messages did not make it
into /var/log/messages, only the dmesg buffer.
This is with standard Ubuntu Gutsy logging levels.
On Thu, 2007-10-04 at 18:42 +0200, Jens Axboe wrote:
> On Thu, Oct 04 2007, Pierre Ossman wrote:
> > On Thu, 04 Oct 2007 09:19:40 -0700
> > Don Mullis <[EMAIL PROTECTED]> wrote:
> >
> > > This patch fixes the boot.
> > >
> >
> > Fantastic. Then will try to get this upstream then.
>
> I already put it in the sgchain drivers part. If you could please ack
> it, that would be nice :-). I have a bunch of driver
> updates/work-arounds there.
>
> > > > It looks like missing init of the sg list in mmc, does this work?
> > > >
> >
> > Jens, is this zeroing needed for each invocation, or really just once
> > to get the list in a known state?
>
> Once should actually be enough, so you could move it to init as well.
> Don, care to verify with the below patch as well?
>
> > Also, is chaining already upstream so Linus should have this for 2.6.23?
>
> No, it's for 2.6.24.
>
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index b0abc7d..a5d0354 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -153,14 +153,14 @@ int mmc_init_queue(struct mmc_queue *mq, struct
> mmc_card *card, spinlock_t *lock
> blk_queue_max_hw_segments(mq->queue, bouncesz / 512);
> blk_queue_max_segment_size(mq->queue, bouncesz);
>
> - mq->sg = kmalloc(sizeof(struct scatterlist),
> + mq->sg = kzalloc(sizeof(struct scatterlist),
> GFP_KERNEL);
> if (!mq->sg) {
> ret = -ENOMEM;
> goto cleanup_queue;
> }
>
> - mq->bounce_sg = kmalloc(sizeof(struct scatterlist) *
> + mq->bounce_sg = kzalloc(sizeof(struct scatterlist) *
> bouncesz / 512, GFP_KERNEL);
> if (!mq->bounce_sg) {
> ret = -ENOMEM;
> @@ -177,7 +177,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
> *card, spinlock_t *lock
> blk_queue_max_hw_segments(mq->queue, host->max_hw_segs);
> blk_queue_max_segment_size(mq->queue, host->max_seg_size);
>
> - mq->sg = kmalloc(sizeof(struct scatterlist) *
> + mq->sg = kzalloc(sizeof(struct scatterlist) *
> host->max_phys_segs, GFP_KERNEL);
> if (!mq->sg) {
> ret = -ENOMEM;
>
-
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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 18:42:25 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > > diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c > index b0abc7d..a5d0354 100644 > --- a/drivers/mmc/card/queue.c > +++ b/drivers/mmc/card/queue.c Acked-by: Pierre Ossman <[EMAIL PROTECTED]> (Provided it works ;)) I have no patches touching queue.c in my tree, so there should be no problems with merge conflicts. Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote:
> On Thu, 04 Oct 2007 09:19:40 -0700
> Don Mullis <[EMAIL PROTECTED]> wrote:
>
> > This patch fixes the boot.
> >
>
> Fantastic. Then will try to get this upstream then.
I already put it in the sgchain drivers part. If you could please ack
it, that would be nice :-). I have a bunch of driver
updates/work-arounds there.
> > > It looks like missing init of the sg list in mmc, does this work?
> > >
>
> Jens, is this zeroing needed for each invocation, or really just once
> to get the list in a known state?
Once should actually be enough, so you could move it to init as well.
Don, care to verify with the below patch as well?
> Also, is chaining already upstream so Linus should have this for 2.6.23?
No, it's for 2.6.24.
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index b0abc7d..a5d0354 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -153,14 +153,14 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card, spinlock_t *lock
blk_queue_max_hw_segments(mq->queue, bouncesz / 512);
blk_queue_max_segment_size(mq->queue, bouncesz);
- mq->sg = kmalloc(sizeof(struct scatterlist),
+ mq->sg = kzalloc(sizeof(struct scatterlist),
GFP_KERNEL);
if (!mq->sg) {
ret = -ENOMEM;
goto cleanup_queue;
}
- mq->bounce_sg = kmalloc(sizeof(struct scatterlist) *
+ mq->bounce_sg = kzalloc(sizeof(struct scatterlist) *
bouncesz / 512, GFP_KERNEL);
if (!mq->bounce_sg) {
ret = -ENOMEM;
@@ -177,7 +177,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card, spinlock_t *lock
blk_queue_max_hw_segments(mq->queue, host->max_hw_segs);
blk_queue_max_segment_size(mq->queue, host->max_seg_size);
- mq->sg = kmalloc(sizeof(struct scatterlist) *
+ mq->sg = kzalloc(sizeof(struct scatterlist) *
host->max_phys_segs, GFP_KERNEL);
if (!mq->sg) {
ret = -ENOMEM;
--
Jens Axboe
-
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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 04 Oct 2007 09:19:40 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > This patch fixes the boot. > Fantastic. Then will try to get this upstream then. > > > > It looks like missing init of the sg list in mmc, does this work? > > Jens, is this zeroing needed for each invocation, or really just once to get the list in a known state? Also, is chaining already upstream so Linus should have this for 2.6.23? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
This patch fixes the boot.
On Thu, 2007-10-04 at 09:25 +0200, Jens Axboe wrote:
> On Wed, Oct 03 2007, Andrew Morton wrote:
> > On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote:
> >
> > > OOPS followed by a 3 minute timeout, then completion of boot.
> > > Not seen if card (Kingston microSD adapter) is ejected; not seen in
> > > 2.6.23-rc8.
> > > Running on a Dell XPS M1330 laptop.
> > >
> > > `dmesg` reports:
> > >
> > > [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB
> > > [ 13.695155] mmcblk0: p1
> > > [ 13.706907] BUG: unable to handle kernel paging request at virtual
> > > address 6b6b6b7a
> > > [ 13.707026] printing eip: c01f09f0 *pde =
> > > [ 13.707174] Oops: [#1] SMP
> > > [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial
> > > [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom
> > > serio_raw mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt
> > > iTCO_vendor_support watchdog_core watchdog_dev cfg80211 mmc_core shpchp
> > > pci_hotplug intel_agp agpgart battery ac power_supply button evdev
> > > ata_generic ext3 jbd mbcache sg sd_mod usbhid hid ahci ata_piix libata
> > > scsi_mod ohci1394 tg3 ieee1394 ehci_hcd uhci_hcd thermal processor fan
> > > fuse
> > > [ 13.709649]
> > > [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27)
> > > [ 13.709767] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
> > > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160
> > > [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100
> > > [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4
> > > [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
> > > [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660
> > > task.ti=c497)
> > > [ 13.710137] last branch before last exception/interrupt
> > > [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340)
> > > [ 13.710359] to c0129c9c (vprintk+0x27c/0x340)
> > > [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000
> > > c3914180 0001 0001
> > > [ 13.710920]1000 c4923700 0100 c48ca3a0
> > > c48f6d88 c48f6d88 c4971e40
> > > [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9
> > > c017de04 0004 c4971e84
> > > [ 13.711857] Call Trace:
> > > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block]
> > > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block]
> > > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block]
> > > [ 13.712309] [] kthread+0x42/0x70
> > > [ 13.712415] [] kernel_thread_helper+0x7/0x14
> > > [ 13.712523] ===
> > > [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29
> > > d0 c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74
> > > 26 00 <8b> 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca
> > > [ 13.71] EIP: [] blk_rq_map_sg+0xc0/0x160 SS:ESP
> > > 0068:c4971df4
> > > [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps:
> > > 0xa04753/0x20
> > > [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7
> > > [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1
> > > across:2731008k
> >
> > This could be due to git-block changes (or a lack of them ;))
>
> It looks like missing init of the sg list in mmc, does this work?
>
> --- linux-2.6.23-rc8/drivers/mmc/card/queue.c~2007-10-04
> 09:22:02.0 +0200
> +++ linux-2.6.23-rc8/drivers/mmc/card/queue.c 2007-10-04 09:23:13.0
> +0200
> @@ -334,14 +334,18 @@ static void copy_sg(struct scatterlist *
>
> unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
> {
> + struct request *rq = mq->req;
> unsigned int sg_len;
>
> - if (!mq->bounce_buf)
> - return blk_rq_map_sg(mq->queue, mq->req, mq->sg);
> + if (!mq->bounce_buf) {
> + memset(mq->sg, 0, rq->nr_hw_segments * sizeof(struct
> scatterlist));
> + return blk_rq_map_sg(mq->queue, rq, mq->sg);
> + }
>
> BUG_ON(!mq->bounce_sg);
>
> - sg_len = blk_rq_map_sg(mq->queue, mq->req, mq->bounce_sg);
> + memset(mq->bounce_sg, 0, rq->nr_hw_segments * sizeof(struct
> scatterlist));
> + sg_len = blk_rq_map_sg(mq->queue, rq, mq->bounce_sg);
>
> mq->bounce_sg_len = sg_len;
>
>
-
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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 12:38:05 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > > > Is that a yes or a no? You said that the ->page field was involved > > > in > > > > It's a conditional yes, re-read it :-) > > > > I didn't get the memo about what chained sg entries entail. It's been posted here several times, but that's ok and it should not matter. I just can't answer your question with a clear yes or no, since it depends on certain situations. > > > list chaining, so does or doesn't it have to be initialized before a > > > call to sg_init_one()? > > > > That's not the problem. It has to be initialized before calling > > blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that > > breaks if that particular sg entry is part of a larger sg table AND > > that sg entry happens to be the chain element. > > > > Ok, then it shouldn't affect my world at least. No, I think mmc is fine, it just needed that memset. > PS. Did someone forget to do a review of all blk_rq_map_sg() callers > before committing the chained list stuff? ;) Apparently this one got missed (and cciss), I'll do a new look just to be on the safe side. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 12:38:05 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > Is that a yes or a no? You said that the ->page field was involved > > in > > It's a conditional yes, re-read it :-) > I didn't get the memo about what chained sg entries entail. > > list chaining, so does or doesn't it have to be initialized before a > > call to sg_init_one()? > > That's not the problem. It has to be initialized before calling > blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that > breaks if that particular sg entry is part of a larger sg table AND > that sg entry happens to be the chain element. > Ok, then it shouldn't affect my world at least. Rgds Pierre PS. Did someone forget to do a review of all blk_rq_map_sg() callers before committing the chained list stuff? ;) signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 11:30:14 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > > > I assume sg_init_one() still can work on an uninitialized sg entry? > > > > Yes, but only if that sg entry is not part of a chained list. > > > > Is that a yes or a no? You said that the ->page field was involved in It's a conditional yes, re-read it :-) > list chaining, so does or doesn't it have to be initialized before a > call to sg_init_one()? That's not the problem. It has to be initialized before calling blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that breaks if that particular sg entry is part of a larger sg table AND that sg entry happens to be the chain element. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 11:30:14 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > I assume sg_init_one() still can work on an uninitialized sg entry? > > Yes, but only if that sg entry is not part of a chained list. > Is that a yes or a no? You said that the ->page field was involved in list chaining, so does or doesn't it have to be initialized before a call to sg_init_one()? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 10:06:32 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > > > Huh? Isn't the block layer supposed to fill in the entire thing? > > > (i.e. current contents shouldn't matter) > > > > Yeah, but sg chaining requires that ->page be filled in properly or it > > could confuse it. I think I'll add some debugging to catch that. > > > > I assume sg_init_one() still can work on an uninitialized sg entry? Yes, but only if that sg entry is not part of a chained list. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 10:06:32 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Oct 04 2007, Pierre Ossman wrote: > > > > Huh? Isn't the block layer supposed to fill in the entire thing? > > (i.e. current contents shouldn't matter) > > Yeah, but sg chaining requires that ->page be filled in properly or it > could confuse it. I think I'll add some debugging to catch that. > I assume sg_init_one() still can work on an uninitialized sg entry? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: > On Thu, 4 Oct 2007 09:25:15 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > It looks like missing init of the sg list in mmc, does this work? > > > > Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. > current contents shouldn't matter) Yeah, but sg chaining requires that ->page be filled in properly or it could confuse it. I think I'll add some debugging to catch that. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 09:25:15 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote: > > It looks like missing init of the sg list in mmc, does this work? > Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. current contents shouldn't matter) Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, 3 Oct 2007 23:16:59 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > > > OOPS followed by a 3 minute timeout, then completion of boot. > > Not seen if card (Kingston microSD adapter) is ejected; not seen in > > 2.6.23-rc8. Running on a Dell XPS M1330 laptop. > > Impossible! My code is bug free! > > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 > > [ 13.711857] Call Trace: > > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block] > > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block] > > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block] Seems to be in the handling of the bounce buffer. I don't see how any of the parameters to blk_rq_map_sg() could be incorrect though, so I suspect the problem is not in the mmc layer. Don, is MMC_BLOCK_BOUNCE enabled? Could you try toggling it and see if things change? > > This could be due to git-block changes (or a lack of them ;)) > There are no pending patches, or recent changes that mess about in any real way in there. Don, when did this work last? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, Oct 03 2007, Andrew Morton wrote:
> On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote:
>
> > OOPS followed by a 3 minute timeout, then completion of boot.
> > Not seen if card (Kingston microSD adapter) is ejected; not seen in
> > 2.6.23-rc8.
> > Running on a Dell XPS M1330 laptop.
> >
> > `dmesg` reports:
> >
> > [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB
> > [ 13.695155] mmcblk0: p1
> > [ 13.706907] BUG: unable to handle kernel paging request at virtual
> > address 6b6b6b7a
> > [ 13.707026] printing eip: c01f09f0 *pde =
> > [ 13.707174] Oops: [#1] SMP
> > [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial
> > [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw
> > mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support
> > watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp
> > agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache
> > sg sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394
> > ehci_hcd uhci_hcd thermal processor fan fuse
> > [ 13.709649]
> > [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27)
> > [ 13.709767] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
> > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160
> > [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100
> > [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4
> > [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
> > [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660
> > task.ti=c497)
> > [ 13.710137] last branch before last exception/interrupt
> > [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340)
> > [ 13.710359] to c0129c9c (vprintk+0x27c/0x340)
> > [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180
> > 0001 0001
> > [ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88
> > c48f6d88 c4971e40
> > [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04
> > 0004 c4971e84
> > [ 13.711857] Call Trace:
> > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block]
> > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block]
> > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block]
> > [ 13.712309] [] kthread+0x42/0x70
> > [ 13.712415] [] kernel_thread_helper+0x7/0x14
> > [ 13.712523] ===
> > [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0
> > c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00
> > <8b> 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca
> > [ 13.71] EIP: [] blk_rq_map_sg+0xc0/0x160 SS:ESP
> > 0068:c4971df4
> > [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps:
> > 0xa04753/0x20
> > [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7
> > [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1
> > across:2731008k
>
> This could be due to git-block changes (or a lack of them ;))
It looks like missing init of the sg list in mmc, does this work?
--- linux-2.6.23-rc8/drivers/mmc/card/queue.c~ 2007-10-04 09:22:02.0
+0200
+++ linux-2.6.23-rc8/drivers/mmc/card/queue.c 2007-10-04 09:23:13.0
+0200
@@ -334,14 +334,18 @@ static void copy_sg(struct scatterlist *
unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
{
+ struct request *rq = mq->req;
unsigned int sg_len;
- if (!mq->bounce_buf)
- return blk_rq_map_sg(mq->queue, mq->req, mq->sg);
+ if (!mq->bounce_buf) {
+ memset(mq->sg, 0, rq->nr_hw_segments * sizeof(struct
scatterlist));
+ return blk_rq_map_sg(mq->queue, rq, mq->sg);
+ }
BUG_ON(!mq->bounce_sg);
- sg_len = blk_rq_map_sg(mq->queue, mq->req, mq->bounce_sg);
+ memset(mq->bounce_sg, 0, rq->nr_hw_segments * sizeof(struct
scatterlist));
+ sg_len = blk_rq_map_sg(mq->queue, rq, mq->bounce_sg);
mq->bounce_sg_len = sg_len;
--
Jens Axboe
-
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/
2.6.23-rc8-mm2: OOPS in mmc on boot
OOPS followed by a 3 minute timeout, then completion of boot. Not seen if card (Kingston microSD adapter) is ejected; not seen in 2.6.23-rc8. Running on a Dell XPS M1330 laptop. `dmesg` reports: [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB [ 13.695155] mmcblk0: p1 [ 13.706907] BUG: unable to handle kernel paging request at virtual address 6b6b6b7a [ 13.707026] printing eip: c01f09f0 *pde = [ 13.707174] Oops: [#1] SMP [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache sg sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394 ehci_hcd uhci_hcd thermal processor fan fuse [ 13.709649] [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27) [ 13.709767] EIP: 0060:[] EFLAGS: 00010206 CPU: 0 [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100 [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4 [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660 task.ti=c497) [ 13.710137] last branch before last exception/interrupt [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340) [ 13.710359] to c0129c9c (vprintk+0x27c/0x340) [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180 0001 0001 [ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88 c48f6d88 c4971e40 [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04 0004 c4971e84 [ 13.711857] Call Trace: [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block] [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block] [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block] [ 13.712309] [] kthread+0x42/0x70 [ 13.712415] [] kernel_thread_helper+0x7/0x14 [ 13.712523] === [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0 c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00 <8b> 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca [ 13.71] EIP: [] blk_rq_map_sg+0xc0/0x160 SS:ESP 0068:c4971df4 [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps: 0xa04753/0x20 [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7 [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1 across:2731008k `lspci -vvv` reports: 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) (prog-if 01) Subsystem: Dell Unknown device 0209 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis <[EMAIL PROTECTED]> wrote: > OOPS followed by a 3 minute timeout, then completion of boot. > Not seen if card (Kingston microSD adapter) is ejected; not seen in > 2.6.23-rc8. > Running on a Dell XPS M1330 laptop. > > `dmesg` reports: > > [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB > [ 13.695155] mmcblk0: p1 > [ 13.706907] BUG: unable to handle kernel paging request at virtual address > 6b6b6b7a > [ 13.707026] printing eip: c01f09f0 *pde = > [ 13.707174] Oops: [#1] SMP > [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial > [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw > mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support > watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp > agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache sg > sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394 > ehci_hcd uhci_hcd thermal processor fan fuse > [ 13.709649] > [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27) > [ 13.709767] EIP: 0060:[] EFLAGS: 00010206 CPU: 0 > [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 > [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100 > [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4 > [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660 > task.ti=c497) > [ 13.710137] last branch before last exception/interrupt > [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340) > [ 13.710359] to c0129c9c (vprintk+0x27c/0x340) > [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180 > 0001 0001 > [ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88 > c48f6d88 c4971e40 > [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04 > 0004 c4971e84 > [ 13.711857] Call Trace: > [ 13.711971] [] mmc_queue_map_sg+0x28/0xc0 [mmc_block] > [ 13.712085] [] mmc_blk_issue_rq+0x199/0x780 [mmc_block] > [ 13.712193] [] mmc_queue_thread+0x78/0xe0 [mmc_block] > [ 13.712309] [] kthread+0x42/0x70 > [ 13.712415] [] kernel_thread_helper+0x7/0x14 > [ 13.712523] === > [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0 c1 > f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00 <8b> > 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca > [ 13.71] EIP: [] blk_rq_map_sg+0xc0/0x160 SS:ESP 0068:c4971df4 > [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps: > 0xa04753/0x20 > [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7 > [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1 > across:2731008k This could be due to git-block changes (or a lack of them ;)) - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis [EMAIL PROTECTED] wrote: OOPS followed by a 3 minute timeout, then completion of boot. Not seen if card (Kingston microSD adapter) is ejected; not seen in 2.6.23-rc8. Running on a Dell XPS M1330 laptop. `dmesg` reports: [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB [ 13.695155] mmcblk0: p1 [ 13.706907] BUG: unable to handle kernel paging request at virtual address 6b6b6b7a [ 13.707026] printing eip: c01f09f0 *pde = [ 13.707174] Oops: [#1] SMP [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache sg sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394 ehci_hcd uhci_hcd thermal processor fan fuse [ 13.709649] [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27) [ 13.709767] EIP: 0060:[c01f09f0] EFLAGS: 00010206 CPU: 0 [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100 [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4 [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660 task.ti=c497) [ 13.710137] last branch before last exception/interrupt [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340) [ 13.710359] to c0129c9c (vprintk+0x27c/0x340) [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180 0001 0001 [ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88 c48f6d88 c4971e40 [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04 0004 c4971e84 [ 13.711857] Call Trace: [ 13.711971] [f8c39e58] mmc_queue_map_sg+0x28/0xc0 [mmc_block] [ 13.712085] [f8c396c9] mmc_blk_issue_rq+0x199/0x780 [mmc_block] [ 13.712193] [f8c3a168] mmc_queue_thread+0x78/0xe0 [mmc_block] [ 13.712309] [c013d382] kthread+0x42/0x70 [ 13.712415] [c0104e73] kernel_thread_helper+0x7/0x14 [ 13.712523] === [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0 c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00 8b 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca [ 13.71] EIP: [c01f09f0] blk_rq_map_sg+0xc0/0x160 SS:ESP 0068:c4971df4 [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps: 0xa04753/0x20 [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7 [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1 across:2731008k This could be due to git-block changes (or a lack of them ;)) - 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/
2.6.23-rc8-mm2: OOPS in mmc on boot
OOPS followed by a 3 minute timeout, then completion of boot. Not seen if card (Kingston microSD adapter) is ejected; not seen in 2.6.23-rc8. Running on a Dell XPS M1330 laptop. `dmesg` reports: [ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB [ 13.695155] mmcblk0: p1 [ 13.706907] BUG: unable to handle kernel paging request at virtual address 6b6b6b7a [ 13.707026] printing eip: c01f09f0 *pde = [ 13.707174] Oops: [#1] SMP [ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial [ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache sg sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394 ehci_hcd uhci_hcd thermal processor fan fuse [ 13.709649] [ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27) [ 13.709767] EIP: 0060:[c01f09f0] EFLAGS: 00010206 CPU: 0 [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 [ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100 [ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4 [ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660 task.ti=c497) [ 13.710137] last branch before last exception/interrupt [ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340) [ 13.710359] to c0129c9c (vprintk+0x27c/0x340) [ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180 0001 0001 [ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88 c48f6d88 c4971e40 [ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04 0004 c4971e84 [ 13.711857] Call Trace: [ 13.711971] [f8c39e58] mmc_queue_map_sg+0x28/0xc0 [mmc_block] [ 13.712085] [f8c396c9] mmc_blk_issue_rq+0x199/0x780 [mmc_block] [ 13.712193] [f8c3a168] mmc_queue_thread+0x78/0xe0 [mmc_block] [ 13.712309] [c013d382] kthread+0x42/0x70 [ 13.712415] [c0104e73] kernel_thread_helper+0x7/0x14 [ 13.712523] === [ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0 c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00 8b 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca [ 13.71] EIP: [c01f09f0] blk_rq_map_sg+0xc0/0x160 SS:ESP 0068:c4971df4 [ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps: 0xa04753/0x20 [ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7 [ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1 across:2731008k `lspci -vvv` reports: 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) (prog-if 01) Subsystem: Dell Unknown device 0209 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 22 Region 0: Memory at fe4ff400 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 03:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12) Subsystem: Dell Unknown device 0209 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 4 Region 0: Memory at fe4ff500 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) Subsystem: Dell Unknown device 0209 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 4 Region 0: Memory at fe4ff600 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, Oct 03 2007, Andrew Morton wrote:
On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis [EMAIL PROTECTED] wrote:
OOPS followed by a 3 minute timeout, then completion of boot.
Not seen if card (Kingston microSD adapter) is ejected; not seen in
2.6.23-rc8.
Running on a Dell XPS M1330 laptop.
`dmesg` reports:
[ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB
[ 13.695155] mmcblk0: p1
[ 13.706907] BUG: unable to handle kernel paging request at virtual
address 6b6b6b7a
[ 13.707026] printing eip: c01f09f0 *pde =
[ 13.707174] Oops: [#1] SMP
[ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial
[ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom serio_raw
mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt iTCO_vendor_support
watchdog_core watchdog_dev cfg80211 mmc_core shpchp pci_hotplug intel_agp
agpgart battery ac power_supply button evdev ata_generic ext3 jbd mbcache
sg sd_mod usbhid hid ahci ata_piix libata scsi_mod ohci1394 tg3 ieee1394
ehci_hcd uhci_hcd thermal processor fan fuse
[ 13.709649]
[ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27)
[ 13.709767] EIP: 0060:[c01f09f0] EFLAGS: 00010206 CPU: 0
[ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160
[ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100
[ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4
[ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
[ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660
task.ti=c497)
[ 13.710137] last branch before last exception/interrupt
[ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340)
[ 13.710359] to c0129c9c (vprintk+0x27c/0x340)
[ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000 c3914180
0001 0001
[ 13.710920]1000 c4923700 0100 c48ca3a0 c48f6d88
c48f6d88 c4971e40
[ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9 c017de04
0004 c4971e84
[ 13.711857] Call Trace:
[ 13.711971] [f8c39e58] mmc_queue_map_sg+0x28/0xc0 [mmc_block]
[ 13.712085] [f8c396c9] mmc_blk_issue_rq+0x199/0x780 [mmc_block]
[ 13.712193] [f8c3a168] mmc_queue_thread+0x78/0xe0 [mmc_block]
[ 13.712309] [c013d382] kthread+0x42/0x70
[ 13.712415] [c0104e73] kernel_thread_helper+0x7/0x14
[ 13.712523] ===
[ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29 d0
c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74 26 00
8b 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca
[ 13.71] EIP: [c01f09f0] blk_rq_map_sg+0xc0/0x160 SS:ESP
0068:c4971df4
[ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps:
0xa04753/0x20
[ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7
[ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1
across:2731008k
This could be due to git-block changes (or a lack of them ;))
It looks like missing init of the sg list in mmc, does this work?
--- linux-2.6.23-rc8/drivers/mmc/card/queue.c~ 2007-10-04 09:22:02.0
+0200
+++ linux-2.6.23-rc8/drivers/mmc/card/queue.c 2007-10-04 09:23:13.0
+0200
@@ -334,14 +334,18 @@ static void copy_sg(struct scatterlist *
unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
{
+ struct request *rq = mq-req;
unsigned int sg_len;
- if (!mq-bounce_buf)
- return blk_rq_map_sg(mq-queue, mq-req, mq-sg);
+ if (!mq-bounce_buf) {
+ memset(mq-sg, 0, rq-nr_hw_segments * sizeof(struct
scatterlist));
+ return blk_rq_map_sg(mq-queue, rq, mq-sg);
+ }
BUG_ON(!mq-bounce_sg);
- sg_len = blk_rq_map_sg(mq-queue, mq-req, mq-bounce_sg);
+ memset(mq-bounce_sg, 0, rq-nr_hw_segments * sizeof(struct
scatterlist));
+ sg_len = blk_rq_map_sg(mq-queue, rq, mq-bounce_sg);
mq-bounce_sg_len = sg_len;
--
Jens Axboe
-
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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Wed, 3 Oct 2007 23:16:59 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis [EMAIL PROTECTED] wrote: OOPS followed by a 3 minute timeout, then completion of boot. Not seen if card (Kingston microSD adapter) is ejected; not seen in 2.6.23-rc8. Running on a Dell XPS M1330 laptop. Impossible! My code is bug free! [ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160 [ 13.711857] Call Trace: [ 13.711971] [f8c39e58] mmc_queue_map_sg+0x28/0xc0 [mmc_block] [ 13.712085] [f8c396c9] mmc_blk_issue_rq+0x199/0x780 [mmc_block] [ 13.712193] [f8c3a168] mmc_queue_thread+0x78/0xe0 [mmc_block] Seems to be in the handling of the bounce buffer. I don't see how any of the parameters to blk_rq_map_sg() could be incorrect though, so I suspect the problem is not in the mmc layer. Don, is MMC_BLOCK_BOUNCE enabled? Could you try toggling it and see if things change? This could be due to git-block changes (or a lack of them ;)) There are no pending patches, or recent changes that mess about in any real way in there. Don, when did this work last? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 09:25:15 +0200 Jens Axboe [EMAIL PROTECTED] wrote: It looks like missing init of the sg list in mmc, does this work? Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. current contents shouldn't matter) Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: On Thu, 4 Oct 2007 09:25:15 +0200 Jens Axboe [EMAIL PROTECTED] wrote: It looks like missing init of the sg list in mmc, does this work? Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. current contents shouldn't matter) Yeah, but sg chaining requires that -page be filled in properly or it could confuse it. I think I'll add some debugging to catch that. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 10:06:32 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Oct 04 2007, Pierre Ossman wrote: Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. current contents shouldn't matter) Yeah, but sg chaining requires that -page be filled in properly or it could confuse it. I think I'll add some debugging to catch that. I assume sg_init_one() still can work on an uninitialized sg entry? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: On Thu, 4 Oct 2007 10:06:32 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Oct 04 2007, Pierre Ossman wrote: Huh? Isn't the block layer supposed to fill in the entire thing? (i.e. current contents shouldn't matter) Yeah, but sg chaining requires that -page be filled in properly or it could confuse it. I think I'll add some debugging to catch that. I assume sg_init_one() still can work on an uninitialized sg entry? Yes, but only if that sg entry is not part of a chained list. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 12:38:05 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Oct 04 2007, Pierre Ossman wrote: Is that a yes or a no? You said that the -page field was involved in It's a conditional yes, re-read it :-) I didn't get the memo about what chained sg entries entail. list chaining, so does or doesn't it have to be initialized before a call to sg_init_one()? That's not the problem. It has to be initialized before calling blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that breaks if that particular sg entry is part of a larger sg table AND that sg entry happens to be the chain element. Ok, then it shouldn't affect my world at least. Rgds Pierre PS. Did someone forget to do a review of all blk_rq_map_sg() callers before committing the chained list stuff? ;) signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 11:30:14 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Oct 04 2007, Pierre Ossman wrote: I assume sg_init_one() still can work on an uninitialized sg entry? Yes, but only if that sg entry is not part of a chained list. Is that a yes or a no? You said that the -page field was involved in list chaining, so does or doesn't it have to be initialized before a call to sg_init_one()? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: On Thu, 4 Oct 2007 11:30:14 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Oct 04 2007, Pierre Ossman wrote: I assume sg_init_one() still can work on an uninitialized sg entry? Yes, but only if that sg entry is not part of a chained list. Is that a yes or a no? You said that the -page field was involved in It's a conditional yes, re-read it :-) list chaining, so does or doesn't it have to be initialized before a call to sg_init_one()? That's not the problem. It has to be initialized before calling blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that breaks if that particular sg entry is part of a larger sg table AND that sg entry happens to be the chain element. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote: On Thu, 4 Oct 2007 12:38:05 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Oct 04 2007, Pierre Ossman wrote: Is that a yes or a no? You said that the -page field was involved in It's a conditional yes, re-read it :-) I didn't get the memo about what chained sg entries entail. It's been posted here several times, but that's ok and it should not matter. I just can't answer your question with a clear yes or no, since it depends on certain situations. list chaining, so does or doesn't it have to be initialized before a call to sg_init_one()? That's not the problem. It has to be initialized before calling blk_rq_map_sg(). sg_init_one() will zero the entire sg entry, and that breaks if that particular sg entry is part of a larger sg table AND that sg entry happens to be the chain element. Ok, then it shouldn't affect my world at least. No, I think mmc is fine, it just needed that memset. PS. Did someone forget to do a review of all blk_rq_map_sg() callers before committing the chained list stuff? ;) Apparently this one got missed (and cciss), I'll do a new look just to be on the safe side. -- Jens Axboe - 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: 2.6.23-rc8-mm2: OOPS in mmc on boot
This patch fixes the boot.
On Thu, 2007-10-04 at 09:25 +0200, Jens Axboe wrote:
On Wed, Oct 03 2007, Andrew Morton wrote:
On Wed, 03 Oct 2007 23:11:02 -0700 Don Mullis [EMAIL PROTECTED] wrote:
OOPS followed by a 3 minute timeout, then completion of boot.
Not seen if card (Kingston microSD adapter) is ejected; not seen in
2.6.23-rc8.
Running on a Dell XPS M1330 laptop.
`dmesg` reports:
[ 13.695045] mmcblk0: mmc0:e95c SD02G 1966080KiB
[ 13.695155] mmcblk0: p1
[ 13.706907] BUG: unable to handle kernel paging request at virtual
address 6b6b6b7a
[ 13.707026] printing eip: c01f09f0 *pde =
[ 13.707174] Oops: [#1] SMP
[ 13.707326] last sysfs file: /class/mmc_host/mmc0/mmc0:e95c/serial
[ 13.707389] Modules linked in: mmc_block sr_mod iwl4965 cdrom
serio_raw mac80211 piix sdhci pcspkr psmouse ide_core iTCO_wdt
iTCO_vendor_support watchdog_core watchdog_dev cfg80211 mmc_core shpchp
pci_hotplug intel_agp agpgart battery ac power_supply button evdev
ata_generic ext3 jbd mbcache sg sd_mod usbhid hid ahci ata_piix libata
scsi_mod ohci1394 tg3 ieee1394 ehci_hcd uhci_hcd thermal processor fan
fuse
[ 13.709649]
[ 13.709705] Pid: 4089, comm: mmcqd Not tainted (2.6.23-rc8-mm2 #27)
[ 13.709767] EIP: 0060:[c01f09f0] EFLAGS: 00010206 CPU: 0
[ 13.709831] EIP is at blk_rq_map_sg+0xc0/0x160
[ 13.709889] EAX: 04b6a000 EBX: c4a030e0 ECX: 04b6b000 EDX: c100
[ 13.709951] ESI: 6b6b6b6a EDI: c11535d0 EBP: c4971e30 ESP: c4971df4
[ 13.710013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
[ 13.710074] Process mmcqd (pid: 4089, ti=c497 task=c387b660
task.ti=c497)
[ 13.710137] last branch before last exception/interrupt
[ 13.710249] from c0129bf8 (vprintk+0x1d8/0x340)
[ 13.710359] to c0129c9c (vprintk+0x27c/0x340)
[ 13.710453] Stack: c4971e08 c013d85f c48a0440 2000 04b6c000
c3914180 0001 0001
[ 13.710920]1000 c4923700 0100 c48ca3a0
c48f6d88 c48f6d88 c4971e40
[ 13.711390]f8c39e58 c48f6d88 c4a9f020 c4971fbc f8c396c9
c017de04 0004 c4971e84
[ 13.711857] Call Trace:
[ 13.711971] [f8c39e58] mmc_queue_map_sg+0x28/0xc0 [mmc_block]
[ 13.712085] [f8c396c9] mmc_blk_issue_rq+0x199/0x780 [mmc_block]
[ 13.712193] [f8c3a168] mmc_queue_thread+0x78/0xe0 [mmc_block]
[ 13.712309] [c013d382] kthread+0x42/0x70
[ 13.712415] [c0104e73] kernel_thread_helper+0x7/0x14
[ 13.712523] ===
[ 13.712584] Code: 0c 03 4f 08 8b 7f 04 01 cf 89 7d d4 8b 3b 89 f8 29
d0 c1 f8 03 69 c0 39 8e e3 38 c1 e0 0c 03 43 08 39 45 d4 74 73 90 8d 74
26 00 8b 46 10 8d 4e 10 89 3e 89 c2 83 e2 fe a8 01 8b 45 e4 0f 45 ca
[ 13.71] EIP: [c01f09f0] blk_rq_map_sg+0xc0/0x160 SS:ESP
0068:c4971df4
[ 13.845668] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1c0b1, caps:
0xa04753/0x20
[ 13.879914] input: SynPS/2 Synaptics TouchPad as /class/input/input7
[ 192.162711] Adding 2731008k swap on /dev/sda7. Priority:-1 extents:1
across:2731008k
This could be due to git-block changes (or a lack of them ;))
It looks like missing init of the sg list in mmc, does this work?
--- linux-2.6.23-rc8/drivers/mmc/card/queue.c~2007-10-04
09:22:02.0 +0200
+++ linux-2.6.23-rc8/drivers/mmc/card/queue.c 2007-10-04 09:23:13.0
+0200
@@ -334,14 +334,18 @@ static void copy_sg(struct scatterlist *
unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
{
+ struct request *rq = mq-req;
unsigned int sg_len;
- if (!mq-bounce_buf)
- return blk_rq_map_sg(mq-queue, mq-req, mq-sg);
+ if (!mq-bounce_buf) {
+ memset(mq-sg, 0, rq-nr_hw_segments * sizeof(struct
scatterlist));
+ return blk_rq_map_sg(mq-queue, rq, mq-sg);
+ }
BUG_ON(!mq-bounce_sg);
- sg_len = blk_rq_map_sg(mq-queue, mq-req, mq-bounce_sg);
+ memset(mq-bounce_sg, 0, rq-nr_hw_segments * sizeof(struct
scatterlist));
+ sg_len = blk_rq_map_sg(mq-queue, rq, mq-bounce_sg);
mq-bounce_sg_len = sg_len;
-
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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 04 Oct 2007 09:19:40 -0700 Don Mullis [EMAIL PROTECTED] wrote: This patch fixes the boot. Fantastic. Then will try to get this upstream then. It looks like missing init of the sg list in mmc, does this work? Jens, is this zeroing needed for each invocation, or really just once to get the list in a known state? Also, is chaining already upstream so Linus should have this for 2.6.23? Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Pierre Ossman wrote:
On Thu, 04 Oct 2007 09:19:40 -0700
Don Mullis [EMAIL PROTECTED] wrote:
This patch fixes the boot.
Fantastic. Then will try to get this upstream then.
I already put it in the sgchain drivers part. If you could please ack
it, that would be nice :-). I have a bunch of driver
updates/work-arounds there.
It looks like missing init of the sg list in mmc, does this work?
Jens, is this zeroing needed for each invocation, or really just once
to get the list in a known state?
Once should actually be enough, so you could move it to init as well.
Don, care to verify with the below patch as well?
Also, is chaining already upstream so Linus should have this for 2.6.23?
No, it's for 2.6.24.
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index b0abc7d..a5d0354 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -153,14 +153,14 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card, spinlock_t *lock
blk_queue_max_hw_segments(mq-queue, bouncesz / 512);
blk_queue_max_segment_size(mq-queue, bouncesz);
- mq-sg = kmalloc(sizeof(struct scatterlist),
+ mq-sg = kzalloc(sizeof(struct scatterlist),
GFP_KERNEL);
if (!mq-sg) {
ret = -ENOMEM;
goto cleanup_queue;
}
- mq-bounce_sg = kmalloc(sizeof(struct scatterlist) *
+ mq-bounce_sg = kzalloc(sizeof(struct scatterlist) *
bouncesz / 512, GFP_KERNEL);
if (!mq-bounce_sg) {
ret = -ENOMEM;
@@ -177,7 +177,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card, spinlock_t *lock
blk_queue_max_hw_segments(mq-queue, host-max_hw_segs);
blk_queue_max_segment_size(mq-queue, host-max_seg_size);
- mq-sg = kmalloc(sizeof(struct scatterlist) *
+ mq-sg = kzalloc(sizeof(struct scatterlist) *
host-max_phys_segs, GFP_KERNEL);
if (!mq-sg) {
ret = -ENOMEM;
--
Jens Axboe
-
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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, 4 Oct 2007 18:42:25 +0200 Jens Axboe [EMAIL PROTECTED] wrote: diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c index b0abc7d..a5d0354 100644 --- a/drivers/mmc/card/queue.c +++ b/drivers/mmc/card/queue.c Acked-by: Pierre Ossman [EMAIL PROTECTED] (Provided it works ;)) I have no patches touching queue.c in my tree, so there should be no problems with merge conflicts. Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.23-rc8-mm2: OOPS in mmc on boot
That patch boots without complaint as well.
BTW, the earlier failure messages did not make it
into /var/log/messages, only the dmesg buffer.
This is with standard Ubuntu Gutsy logging levels.
On Thu, 2007-10-04 at 18:42 +0200, Jens Axboe wrote:
On Thu, Oct 04 2007, Pierre Ossman wrote:
On Thu, 04 Oct 2007 09:19:40 -0700
Don Mullis [EMAIL PROTECTED] wrote:
This patch fixes the boot.
Fantastic. Then will try to get this upstream then.
I already put it in the sgchain drivers part. If you could please ack
it, that would be nice :-). I have a bunch of driver
updates/work-arounds there.
It looks like missing init of the sg list in mmc, does this work?
Jens, is this zeroing needed for each invocation, or really just once
to get the list in a known state?
Once should actually be enough, so you could move it to init as well.
Don, care to verify with the below patch as well?
Also, is chaining already upstream so Linus should have this for 2.6.23?
No, it's for 2.6.24.
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index b0abc7d..a5d0354 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -153,14 +153,14 @@ int mmc_init_queue(struct mmc_queue *mq, struct
mmc_card *card, spinlock_t *lock
blk_queue_max_hw_segments(mq-queue, bouncesz / 512);
blk_queue_max_segment_size(mq-queue, bouncesz);
- mq-sg = kmalloc(sizeof(struct scatterlist),
+ mq-sg = kzalloc(sizeof(struct scatterlist),
GFP_KERNEL);
if (!mq-sg) {
ret = -ENOMEM;
goto cleanup_queue;
}
- mq-bounce_sg = kmalloc(sizeof(struct scatterlist) *
+ mq-bounce_sg = kzalloc(sizeof(struct scatterlist) *
bouncesz / 512, GFP_KERNEL);
if (!mq-bounce_sg) {
ret = -ENOMEM;
@@ -177,7 +177,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card, spinlock_t *lock
blk_queue_max_hw_segments(mq-queue, host-max_hw_segs);
blk_queue_max_segment_size(mq-queue, host-max_seg_size);
- mq-sg = kmalloc(sizeof(struct scatterlist) *
+ mq-sg = kzalloc(sizeof(struct scatterlist) *
host-max_phys_segs, GFP_KERNEL);
if (!mq-sg) {
ret = -ENOMEM;
-
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: 2.6.23-rc8-mm2: OOPS in mmc on boot
On Thu, Oct 04 2007, Don Mullis wrote: That patch boots without complaint as well. BTW, the earlier failure messages did not make it into /var/log/messages, only the dmesg buffer. This is with standard Ubuntu Gutsy logging levels. Super, thanks for retesting! -- Jens Axboe - 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 0/2] Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
I have broken the Smack patch into the netlabel changes from Paul Moore (1/2) and the Smack LSM (2/2), at Paul's kind suggestion. The smackfs symlinks have proven too contentious. I have removed the facility. Al and Alan are correct that the rich set of mount options currently available can handle any of the use cases I was looking at without excessive difficulty. I think that is the last of the major issues. I'm sure that if there are more y'all will let me know. Thank you. - 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 1/2] [NetLabel] Introduce a new kernel configuration API for NetLabel - Version 5 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
From: Paul Moore [EMAIL PROTECTED]
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
Signed-off-by: Casey Schaufler [EMAIL PROTECTED]
---
include/net/netlabel.h | 47 --
net/ipv4/cipso_ipv4.c |4 -
net/netlabel/netlabel_cipso_v4.c |2
net/netlabel/netlabel_cipso_v4.h |3 +
net/netlabel/netlabel_domainhash.h |1
net/netlabel/netlabel_kapi.c | 174
6 files changed, 222 insertions(+), 9 deletions(-)
diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
#include net/netlink.h
#include asm/atomic.h
+struct cipso_v4_doi;
+
/*
* NetLabel - A management interface for maintaining network packet label
*mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
};
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
/* LSM security attributes */
struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct
netlbl_lsm_secattr *secattr)
#ifdef CONFIG_NETLABEL
/*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+ const char *domain,
+ struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
* LSM security attribute operations
*/
int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
int netlbl_cache_add(const struct sk_buff *skb,
const struct netlbl_lsm_secattr *secattr);
#else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+ struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+ return -ENOSYS;
+}
static inline int netlbl_secattr_catmap_walk(
struct netlbl_lsm_secattr_catmap *catmap,
u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ab56a05..714461c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -557,8 +557,8 @@ int cipso_v4_doi_remove(u32 doi,
spin_unlock(cipso_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
- netlbl_domhsh_remove(dom_iter-domain,
-audit_info);
+ netlbl_cfg_map_del(dom_iter-domain,
+ audit_info);
cipso_v4_cache_invalidate();
rcu_read_unlock();
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index c060e3f..07f7fd4 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
* safely.
*
*/
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
{
struct cipso_v4_doi *ptr;
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
/* NetLabel protocol functions */
int netlbl_cipsov4_genl_init(void);
+/*
Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: > > 1. Create /moldy at "_" > > 2. For each label you care about > >2a. Create /moldy/ > >2b. Set the label of /moldy/ to > > 3. ln -s /smack/tmp /tmp > > > 1. Create /moldy at "_" > > 2. For each label you care about > >2a. Create /moldy/ > >2b. Set the label of /moldy/ to > > 3. ln -s /smack/tmp.link /tmp > 4. mount --bind /moldy /smack/tmp > or add > /moldy /smack/tmp none bind,rw 0 2 > to /etc/fstab (same effect as (4)) > > Compare with your variant; the difference is in one argument of ln(1) and > one additional line in rc script or /etc/fstab. Sorry, but I don't buy > the "extra setup complexity" argument at all. What I'm confused about is how that results in a process labeled "foo" getting a different /tmp from a process labeled "bar". I guess I'll have to review your first post. > > It's the content of a symlink, and that can be just about anything > > and is not required to point to anything, which is one reason why > > I made that choice. If you don't have a /tmp, or can't write to the > > /tmp that exists, or have a /tmp that's a dangling symlink under > > any circumstances you may have an issue. That's true regardless of > > the presence or absense of /smack. All of the traditional mechanisms > > for dealing with /tmp in a chrooted or namespaced environment remain. > > It's not about symlink pointing to /smack/; it's about the place > where /smack/ itself points to. And _that_ can bloody well be > different in different chroots. Which is completely OK with me. > Look, if you allow to change where it goes, you certainly allow different > prefices on different boxen; moreover, admin can change it freely according > to his layout on given box. OTOH, you _can't_ have it different in different > chroots and changing it in one will affect all of them. See why that's a > problem? Yes, I can see that could be an unexpected behavior. > > It's in a symlink on the filesystem, and it doesn't have to be an > > absolute pathname, although since it's a symlink and the semantics > > for a symlink allow that be be absolute, relative, or dangling I > > don't see any reason to restrict it from being absolute. > > Fixed-contents symlink (with or without variable tail - it's irrelevant > here) is a bloody wrong tool for that kind of fs for the reasons described > above. I do not understand where the concept of Fixed-contents symlink comes from. Yes, "tmp" is initialized to "/moldy/", but that can be changed by writing to /smack/links. Please help me understand the what you mean by fixed-contents symlinks. > And if you go for "prefix should point to location on the same fs" > you can trivially configure the rest in userland (one line describing a > binding), leaving the kernel-side stuff with something like "userland > can ask for a pair of symlink and directory, having symlink resolve > to directory + " instead of your "userland can ask for a symlink > resolving to + ". And _that_ is chroot-neutral - you don't > need to do any extra work... > > > Could allowing multiple distinct mounts and symlink assignments > > of /smackfs address those issues? > > ... like that one. Leave it to normal userland mechanisms; it's a matter > of a single line in whatever script you are using to set chroot up and it > involves _way_ fewer caveats. > > That said, Alan's point still stands - if you don't get processes changing > context back and forth, you don't need anything at all - we already have > all we need for that kind of setups (and no, selinux is not involved ;-). Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: > 1. Create /moldy at "_" > 2. For each label you care about >2a. Create /moldy/ >2b. Set the label of /moldy/ to > 3. ln -s /smack/tmp /tmp > 1. Create /moldy at "_" > 2. For each label you care about >2a. Create /moldy/ >2b. Set the label of /moldy/ to > 3. ln -s /smack/tmp.link /tmp 4. mount --bind /moldy /smack/tmp or add /moldy /smack/tmp none bind,rw 0 2 to /etc/fstab (same effect as (4)) Compare with your variant; the difference is in one argument of ln(1) and one additional line in rc script or /etc/fstab. Sorry, but I don't buy the "extra setup complexity" argument at all. > It's the content of a symlink, and that can be just about anything > and is not required to point to anything, which is one reason why > I made that choice. If you don't have a /tmp, or can't write to the > /tmp that exists, or have a /tmp that's a dangling symlink under > any circumstances you may have an issue. That's true regardless of > the presence or absense of /smack. All of the traditional mechanisms > for dealing with /tmp in a chrooted or namespaced environment remain. It's not about symlink pointing to /smack/; it's about the place where /smack/ itself points to. And _that_ can bloody well be different in different chroots. Look, if you allow to change where it goes, you certainly allow different prefices on different boxen; moreover, admin can change it freely according to his layout on given box. OTOH, you _can't_ have it different in different chroots and changing it in one will affect all of them. See why that's a problem? > It's in a symlink on the filesystem, and it doesn't have to be an > absolute pathname, although since it's a symlink and the semantics > for a symlink allow that be be absolute, relative, or dangling I > don't see any reason to restrict it from being absolute. Fixed-contents symlink (with or without variable tail - it's irrelevant here) is a bloody wrong tool for that kind of fs for the reasons described above. And if you go for "prefix should point to location on the same fs" you can trivially configure the rest in userland (one line describing a binding), leaving the kernel-side stuff with something like "userland can ask for a pair of symlink and directory, having symlink resolve to directory + " instead of your "userland can ask for a symlink resolving to + ". And _that_ is chroot-neutral - you don't need to do any extra work... > Could allowing multiple distinct mounts and symlink assignments > of /smackfs address those issues? ... like that one. Leave it to normal userland mechanisms; it's a matter of a single line in whatever script you are using to set chroot up and it involves _way_ fewer caveats. That said, Alan's point still stands - if you don't get processes changing context back and forth, you don't need anything at all - we already have all we need for that kind of setups (and no, selinux is not involved ;-). - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: > > > > Because you throw "simple" out the window when you require userland > > > > assistance to perform this function. > > > > > > Any more than having /tmp replaced with a symlink? > > > > Yes. By the way, there's nothing that really requires that you > > use a /smack symlink if you don't want to. /tmp can still be a > > real directory, a mount point, a symlink to /var/tmp, or whatever > > else you want it to be if that suits your needs better. For the > > simplest scenarios /tmp -> /smack/tmp -> /moldy/ has every > > other scheme I've seen throughly beaten. > > And your point is? If you don't use it, you get exact same complexity > in both setups. Thank you for your patience. Let me see if I can get my point across. The intended Smack scenario: 1. Create /moldy at "_" 2. For each label you care about 2a. Create /moldy/ 2b. Set the label of /moldy/ to 3. ln -s /smack/tmp /tmp All processes are now redirected into the appropriate place regardless of how they come into being. It doesn't matter if the "session" starts from busybox, login, sshd, xdm, crontab, or out of an init script. > > > _What_ userland intervention? Mounting stuff under /smack/tmp and not > under > > > your /moldy? > > > > Who said anything about mounting under /moldy? I never did. > > Sigh... So put the binding into fstab and be done with that. Are you suggesting that /smack/tmp.link below is a mount point, and that appropriate directories get mounted there? 1. Create /moldy at "_" 2. For each label you care about 2a. Create /moldy/ 2b. Set the label of /moldy/ to 2c. mount --bind /moldy/ /smack/tmp.link/ 3. ln -s /smack/tmp.link /tmp > > > Having /tmp replaced with symlink to /smack/tmp.link instead > > > of replacing it with a symlink to /smack/tmp? > > > > > > Absolute paths in that kind of thing are _wrong_. You know where the > things > > > are on your fs. You don't know if anything else will be visible, let > alone > > > whether it will be at the same place in all chroots or namespaces. And > no, > > > you _can't_ make sure that fs is visible only in one place. No fs can or > > > has any business even trying. > > > > Is the objection that there is a default value coded in? > > Right now the main objection is about your lack of ability to read. Now you sound like my daughter. :-) > Which > part of "it can be mounted in different chroots/namespaces, therefore > having absolute paths doesn't work" is too hard to understand? It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. > No, it's not about having a default. Nuts. That would have made addressing your concern easy. > It's about keeping an absolute pathname in virtual fs, It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. > having all instances autosoddingmatically sharing it _and_ > having change attempt in any instance automatically affect all of them. > If you have that kind of sharing, don't pretend that your mechanism really > allows absolute pathnames. Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? I think it would, but as you pointed out earlier, my lack of ability to read may be clouding my understanding. Thank you. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox <[EMAIL PROTECTED]> wrote: > > An embedded system that does not have user logins but that does > > have applications that require separation, perhaps a moble communication > > device with application download capability, is just one example > > where the smack symlink implementation provides the required > > function without requiring application support. > > I don't see what is such a problem here. For your mobile example you'd > give the application download side its own /tmp via mount. > > Its actually better this is done in user space as its more flexible that > way and can be tuned arbitarily to meet interesting or bizarre real world > cases. I admit to being impressed by the wide variety of mount options currently available. In many cases this will be the best approach. /tmp is a typical use for a smack symlink, but not the only one. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: > > > Because you throw "simple" out the window when you require userland > > > assistance to perform this function. > > > > Any more than having /tmp replaced with a symlink? > > Yes. By the way, there's nothing that really requires that you > use a /smack symlink if you don't want to. /tmp can still be a > real directory, a mount point, a symlink to /var/tmp, or whatever > else you want it to be if that suits your needs better. For the > simplest scenarios /tmp -> /smack/tmp -> /moldy/ has every > other scheme I've seen throughly beaten. And your point is? If you don't use it, you get exact same complexity in both setups. > > _What_ userland intervention? Mounting stuff under /smack/tmp and not under > > your /moldy? > > Who said anything about mounting under /moldy? I never did. Sigh... So put the binding into fstab and be done with that. > > Having /tmp replaced with symlink to /smack/tmp.link instead > > of replacing it with a symlink to /smack/tmp? > > > > Absolute paths in that kind of thing are _wrong_. You know where the things > > are on your fs. You don't know if anything else will be visible, let alone > > whether it will be at the same place in all chroots or namespaces. And no, > > you _can't_ make sure that fs is visible only in one place. No fs can or > > has any business even trying. > > Is the objection that there is a default value coded in? Right now the main objection is about your lack of ability to read. Which part of "it can be mounted in different chroots/namespaces, therefore having absolute paths doesn't work" is too hard to understand? No, it's not about having a default. It's about keeping an absolute pathname in virtual fs, having all instances autosoddingmatically sharing it _and_ having change attempt in any instance automatically affect all of them. If you have that kind of sharing, don't pretend that your mechanism really allows absolute pathnames. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
> An embedded system that does not have user logins but that does > have applications that require separation, perhaps a moble communication > device with application download capability, is just one example > where the smack symlink implementation provides the required > function without requiring application support. I don't see what is such a problem here. For your mobile example you'd give the application download side its own /tmp via mount. Its actually better this is done in user space as its more flexible that way and can be tuned arbitarily to meet interesting or bizarre real world cases. 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox <[EMAIL PROTECTED]> wrote: > > Absolute paths in that kind of thing are _wrong_. You know where the > things > > are on your fs. You don't know if anything else will be visible, let alone > > whether it will be at the same place in all chroots or namespaces. And no, > > you _can't_ make sure that fs is visible only in one place. No fs can or > > has any business even trying. > > What I don't understand here is why we need the hacks when we already > support sufficient mount magic to give each login session its own > private /tmp ? An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: > > > what > > > happens if we want it in two chroot jails with different layouts? > > > > As you can only have /smack mounted once, this isn't an issue, > > but it does present an interesting use case that brings the one > > mount limitation into question. I'll add addressing this to the > > short term todo list. > > Of course you can mount it more than once. Just bind the sucker and you > are done. > > > > I really don't get it; why not simply have something like > > > /smack/tmp.link resolve to tmp/ and have userland bind or mount > > > whatever you bloody like on /smack/tmp? > > > > Because you throw "simple" out the window when you require userland > > assistance to perform this function. > > Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp -> /smack/tmp -> /moldy/ has every other scheme I've seen throughly beaten. > > I'm having some trouble seeing how the 60 lines of code in > > smackfs dealing with symlinks would be improved by your suggestions. > > I certainly don't see how requiring userland intervention would > > do anything but make it bigger and less reliable. > > _What_ userland intervention? Mounting stuff under /smack/tmp and not under > your /moldy? Who said anything about mounting under /moldy? I never did. > Having /tmp replaced with symlink to /smack/tmp.link instead > of replacing it with a symlink to /smack/tmp? > > Absolute paths in that kind of thing are _wrong_. You know where the things > are on your fs. You don't know if anything else will be visible, let alone > whether it will be at the same place in all chroots or namespaces. And no, > you _can't_ make sure that fs is visible only in one place. No fs can or > has any business even trying. Is the objection that there is a default value coded in? Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 07:17:35PM +0100, Alan Cox wrote: > > Absolute paths in that kind of thing are _wrong_. You know where the things > > are on your fs. You don't know if anything else will be visible, let alone > > whether it will be at the same place in all chroots or namespaces. And no, > > you _can't_ make sure that fs is visible only in one place. No fs can or > > has any business even trying. > > What I don't understand here is why we need the hacks when we already > support sufficient mount magic to give each login session its own > private /tmp ? Presumably his context can change within a login session? If not, it's indeed simply worthless, absolute paths or not. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
> Absolute paths in that kind of thing are _wrong_. You know where the things > are on your fs. You don't know if anything else will be visible, let alone > whether it will be at the same place in all chroots or namespaces. And no, > you _can't_ make sure that fs is visible only in one place. No fs can or > has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: > > what > > happens if we want it in two chroot jails with different layouts? > > As you can only have /smack mounted once, this isn't an issue, > but it does present an interesting use case that brings the one > mount limitation into question. I'll add addressing this to the > short term todo list. Of course you can mount it more than once. Just bind the sucker and you are done. > > I really don't get it; why not simply have something like > > /smack/tmp.link resolve to tmp/ and have userland bind or mount > > whatever you bloody like on /smack/tmp? > > Because you throw "simple" out the window when you require userland > assistance to perform this function. Any more than having /tmp replaced with a symlink? > I'm having some trouble seeing how the 60 lines of code in > smackfs dealing with symlinks would be improved by your suggestions. > I certainly don't see how requiring userland intervention would > do anything but make it bigger and less reliable. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: > > > > From: Casey Schaufler <[EMAIL PROTECTED]> > > > > Smack is the Simplified Mandatory Access Control Kernel. > > > > Smack implements mandatory access control (MAC) using labels > > attached to tasks and data containers, including files, SVIPC, > > and other tasks. Smack is a kernel based scheme that requires > > an absolute minimum of application support and a very small > > amount of configuration data. > > I _really_ don't like what you are doing with these symlinks. > For one thing, you have no exclusion between reading the list > entries and modifying them. That's easy enough to fix. I'll do it. > For another... WTF is filesystem > making assumptions about the locations where the things are > mounted? I assume by this that you're objecting to the initialization of /smack/tmp to point to /moldy/. Over the years I've seen a number of cases where failure to set up /tmp result in unhappy consequences. If /tmp is anything other than a real directory on the root filesystem it is important that special care be taken for the case where things don't get set up right for some reason. By including a specific, if perhaps arbitrary, default it becomes easier to create a configuration that survives the unexpected. > Hell, even if you override your tmp symlink, Which is something that I expect virtually everyone to do. > what > happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. > I really don't get it; why not simply have something like > /smack/tmp.link resolve to tmp/ and have userland bind or mount > whatever you bloody like on /smack/tmp? Because you throw "simple" out the window when you require userland assistance to perform this function. > No problems with absolute > paths, can be used in chroot jails with whatever layouts, ditto for > namespaces, etc. and both symlink and directory get created at > the same time (by one name). Hell, if you keep a reference > to dentry of directory in the data associated with symlink, > you can simply switch nd->dentry to that, drop the old one > and grab the reference to page containing label and return > it via nd_set_link(). No need to play with allocations, strcat, > yadda, yadda. readlink() can stuff the ->d_name of the same > dentry plus / plus label directly into user buffer; again, no > allocations needed and works fine anywhere. I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wednesday 03 October 2007 12:45:42 am Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> Smack is the Simplified Mandatory Access Control Kernel.
>
> Smack implements mandatory access control (MAC) using labels
> attached to tasks and data containers, including files, SVIPC,
> and other tasks. Smack is a kernel based scheme that requires
> an absolute minimum of application support and a very small
> amount of configuration data.
>
> {snip}
>
> This patch includes changes made by Paul Moore <[EMAIL PROTECTED]>
> in support of a more comfortable interface to initialize the
> CIPSO code from within the kernel. The changes in the net directory
> are Pauls, as is the update to netlabel.h
My sign-off got lost when Casey smooshed the patch I sent him into the SMACK
mega-patch so I'll throw it back in the thread for accounting purposes.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
As for SMACK's use of NetLabel - it looks fine to me, especially now that
there is better preservation of the NetLabel/LSM boundary. As has been
discussed on the various lists during earlier revisions of the patch I
believe there are still some optimizations that can be made regarding how
SMACK uses NetLabel but that is something we can always work on at a later
date.
Acked-by: Paul Moore <[EMAIL PROTECTED]>
--
paul moore
linux security @ hp
-
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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wednesday 03 October 2007 12:45:42 am Casey Schaufler wrote:
From: Casey Schaufler [EMAIL PROTECTED]
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and other tasks. Smack is a kernel based scheme that requires
an absolute minimum of application support and a very small
amount of configuration data.
{snip}
This patch includes changes made by Paul Moore [EMAIL PROTECTED]
in support of a more comfortable interface to initialize the
CIPSO code from within the kernel. The changes in the net directory
are Pauls, as is the update to netlabel.h
My sign-off got lost when Casey smooshed the patch I sent him into the SMACK
mega-patch so I'll throw it back in the thread for accounting purposes.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
As for SMACK's use of NetLabel - it looks fine to me, especially now that
there is better preservation of the NetLabel/LSM boundary. As has been
discussed on the various lists during earlier revisions of the patch I
believe there are still some optimizations that can be made regarding how
SMACK uses NetLabel but that is something we can always work on at a later
date.
Acked-by: Paul Moore [EMAIL PROTECTED]
--
paul moore
linux security @ hp
-
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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: From: Casey Schaufler [EMAIL PROTECTED] Smack is the Simplified Mandatory Access Control Kernel. Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data. I _really_ don't like what you are doing with these symlinks. For one thing, you have no exclusion between reading the list entries and modifying them. That's easy enough to fix. I'll do it. For another... WTF is filesystem making assumptions about the locations where the things are mounted? I assume by this that you're objecting to the initialization of /smack/tmp to point to /moldy/label. Over the years I've seen a number of cases where failure to set up /tmp result in unhappy consequences. If /tmp is anything other than a real directory on the root filesystem it is important that special care be taken for the case where things don't get set up right for some reason. By including a specific, if perhaps arbitrary, default it becomes easier to create a configuration that survives the unexpected. Hell, even if you override your tmp symlink, Which is something that I expect virtually everyone to do. what happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? Because you throw simple out the window when you require userland assistance to perform this function. No problems with absolute paths, can be used in chroot jails with whatever layouts, ditto for namespaces, etc. and both symlink and directory get created at the same time (by one name). Hell, if you keep a reference to dentry of directory in the data associated with symlink, you can simply switch nd-dentry to that, drop the old one and grab the reference to page containing label and return it via nd_set_link(). No need to play with allocations, strcat, yadda, yadda. readlink() can stuff the -d_name of the same dentry plus / plus label directly into user buffer; again, no allocations needed and works fine anywhere. I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: what happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. Of course you can mount it more than once. Just bind the sucker and you are done. I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 07:17:35PM +0100, Alan Cox wrote: Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? Presumably his context can change within a login session? If not, it's indeed simply worthless, absolute paths or not. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: what happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. Of course you can mount it more than once. Just bind the sucker and you are done. I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp - /smack/tmp - /moldy/label has every other scheme I've seen throughly beaten. I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Who said anything about mounting under /moldy? I never did. Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. Is the objection that there is a default value coded in? Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox [EMAIL PROTECTED] wrote: Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. I don't see what is such a problem here. For your mobile example you'd give the application download side its own /tmp via mount. Its actually better this is done in user space as its more flexible that way and can be tuned arbitarily to meet interesting or bizarre real world cases. 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp - /smack/tmp - /moldy/label has every other scheme I've seen throughly beaten. And your point is? If you don't use it, you get exact same complexity in both setups. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Who said anything about mounting under /moldy? I never did. Sigh... So put the binding into fstab and be done with that. Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. Is the objection that there is a default value coded in? Right now the main objection is about your lack of ability to read. Which part of it can be mounted in different chroots/namespaces, therefore having absolute paths doesn't work is too hard to understand? No, it's not about having a default. It's about keeping an absolute pathname in virtual fs, having all instances autosoddingmatically sharing it _and_ having change attempt in any instance automatically affect all of them. If you have that kind of sharing, don't pretend that your mechanism really allows absolute pathnames. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox [EMAIL PROTECTED] wrote: An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. I don't see what is such a problem here. For your mobile example you'd give the application download side its own /tmp via mount. Its actually better this is done in user space as its more flexible that way and can be tuned arbitarily to meet interesting or bizarre real world cases. I admit to being impressed by the wide variety of mount options currently available. In many cases this will be the best approach. /tmp is a typical use for a smack symlink, but not the only one. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp - /smack/tmp - /moldy/label has every other scheme I've seen throughly beaten. And your point is? If you don't use it, you get exact same complexity in both setups. Thank you for your patience. Let me see if I can get my point across. The intended Smack scenario: 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp /tmp All processes are now redirected into the appropriate place regardless of how they come into being. It doesn't matter if the session starts from busybox, login, sshd, xdm, crontab, or out of an init script. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Who said anything about mounting under /moldy? I never did. Sigh... So put the binding into fstab and be done with that. Are you suggesting that /smack/tmp.link below is a mount point, and that appropriate directories get mounted there? 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 2c. mount --bind /moldy/label /smack/tmp.link/label 3. ln -s /smack/tmp.link /tmp Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. Is the objection that there is a default value coded in? Right now the main objection is about your lack of ability to read. Now you sound like my daughter. :-) Which part of it can be mounted in different chroots/namespaces, therefore having absolute paths doesn't work is too hard to understand? It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. No, it's not about having a default. Nuts. That would have made addressing your concern easy. It's about keeping an absolute pathname in virtual fs, It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. having all instances autosoddingmatically sharing it _and_ having change attempt in any instance automatically affect all of them. If you have that kind of sharing, don't pretend that your mechanism really allows absolute pathnames. Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? I think it would, but as you pointed out earlier, my lack of ability to read may be clouding my understanding. Thank you. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp /tmp 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp.link /tmp 4. mount --bind /moldy /smack/tmp or add /moldy /smack/tmp none bind,rw 0 2 to /etc/fstab (same effect as (4)) Compare with your variant; the difference is in one argument of ln(1) and one additional line in rc script or /etc/fstab. Sorry, but I don't buy the extra setup complexity argument at all. It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. It's not about symlink pointing to /smack/something; it's about the place where /smack/something itself points to. And _that_ can bloody well be different in different chroots. Look, if you allow to change where it goes, you certainly allow different prefices on different boxen; moreover, admin can change it freely according to his layout on given box. OTOH, you _can't_ have it different in different chroots and changing it in one will affect all of them. See why that's a problem? It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. Fixed-contents symlink (with or without variable tail - it's irrelevant here) is a bloody wrong tool for that kind of fs for the reasons described above. And if you go for prefix should point to location on the same fs you can trivially configure the rest in userland (one line describing a binding), leaving the kernel-side stuff with something like userland can ask for a pair of symlink and directory, having symlink resolve to directory + label instead of your userland can ask for a symlink resolving to prefix + label. And _that_ is chroot-neutral - you don't need to do any extra work... Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? ... like that one. Leave it to normal userland mechanisms; it's a matter of a single line in whatever script you are using to set chroot up and it involves _way_ fewer caveats. That said, Alan's point still stands - if you don't get processes changing context back and forth, you don't need anything at all - we already have all we need for that kind of setups (and no, selinux is not involved ;-). - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp /tmp 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp.link /tmp 4. mount --bind /moldy /smack/tmp or add /moldy /smack/tmp none bind,rw 0 2 to /etc/fstab (same effect as (4)) Compare with your variant; the difference is in one argument of ln(1) and one additional line in rc script or /etc/fstab. Sorry, but I don't buy the extra setup complexity argument at all. What I'm confused about is how that results in a process labeled foo getting a different /tmp from a process labeled bar. I guess I'll have to review your first post. It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. It's not about symlink pointing to /smack/something; it's about the place where /smack/something itself points to. And _that_ can bloody well be different in different chroots. Which is completely OK with me. Look, if you allow to change where it goes, you certainly allow different prefices on different boxen; moreover, admin can change it freely according to his layout on given box. OTOH, you _can't_ have it different in different chroots and changing it in one will affect all of them. See why that's a problem? Yes, I can see that could be an unexpected behavior. It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. Fixed-contents symlink (with or without variable tail - it's irrelevant here) is a bloody wrong tool for that kind of fs for the reasons described above. I do not understand where the concept of Fixed-contents symlink comes from. Yes, tmp is initialized to /moldy/, but that can be changed by writing to /smack/links. Please help me understand the what you mean by fixed-contents symlinks. And if you go for prefix should point to location on the same fs you can trivially configure the rest in userland (one line describing a binding), leaving the kernel-side stuff with something like userland can ask for a pair of symlink and directory, having symlink resolve to directory + label instead of your userland can ask for a symlink resolving to prefix + label. And _that_ is chroot-neutral - you don't need to do any extra work... Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? ... like that one. Leave it to normal userland mechanisms; it's a matter of a single line in whatever script you are using to set chroot up and it involves _way_ fewer caveats. That said, Alan's point still stands - if you don't get processes changing context back and forth, you don't need anything at all - we already have all we need for that kind of setups (and no, selinux is not involved ;-). Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: > > From: Casey Schaufler <[EMAIL PROTECTED]> > > Smack is the Simplified Mandatory Access Control Kernel. > > Smack implements mandatory access control (MAC) using labels > attached to tasks and data containers, including files, SVIPC, > and other tasks. Smack is a kernel based scheme that requires > an absolute minimum of application support and a very small > amount of configuration data. I _really_ don't like what you are doing with these symlinks. For one thing, you have no exclusion between reading the list entries and modifying them. For another... WTF is filesystem making assumptions about the locations where the things are mounted? Hell, even if you override your tmp symlink, what happens if we want it in two chroot jails with different layouts? I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/ and have userland bind or mount whatever you bloody like on /smack/tmp? No problems with absolute paths, can be used in chroot jails with whatever layouts, ditto for namespaces, etc. and both symlink and directory get created at the same time (by one name). Hell, if you keep a reference to dentry of directory in the data associated with symlink, you can simply switch nd->dentry to that, drop the old one and grab the reference to page containing label and return it via nd_set_link(). No need to play with allocations, strcat, yadda, yadda. readlink() can stuff the ->d_name of the same dentry plus / plus label directly into user buffer; again, no allocations needed and works fine anywhere. - 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: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
> On Tue, 2 Oct 2007, Ilpo Järvinen wrote: > > > I'm currently out of ideas where it could come from... Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after all, or in fact, two of them. I'll post patch for this tomorrow... -- i.
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
> I'm currently out of ideas where it could come from... so lets try
> brute-force checking as your test case is not very high-speed... This
> could hide it though... :-(
>
> Please put the patch below on top of clean rc8-mm2 (it includes the patch
> I gave you last time) and try to reproduce These counter bugs can
> survive for sometime until !sacked_out condition occurs, so the patch
> below tries to find that out when inconsisteny occurs for the first time
> regardless of sacked_out (I also removed some statics which hopefully
> reduces compiler inlining for easier reading of the output). I tried this
> myself (except for verify()s in frto funcs and minor printout
> modifications), didn't trigger for me.
In case you haven't yet get started (or it's easy enough to replace),
please use the one below instead (I forgot one counter from printout
in the last patch, which might turn out useful...).
--
i.
---
include/net/tcp.h |3 +
net/ipv4/tcp_input.c | 23 +--
net/ipv4/tcp_ipv4.c | 103 +
net/ipv4/tcp_output.c |6 ++-
4 files changed, 129 insertions(+), 6 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 991ccdc..54a0d91 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,9 @@
#include
+extern void tcp_verify_fackets(struct sock *sk);
+extern void tcp_print_queue(struct sock *sk);
+
extern struct inet_hashinfo tcp_hashinfo;
extern atomic_t tcp_orphan_count;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e22ffe7..1d7367d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1140,7 +1140,7 @@ static int tcp_check_dsack(struct tcp_sock *tp, struct
sk_buff *ack_skb,
return dup_sack;
}
-static int
+int
tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32
prior_snd_una)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1160,6 +1160,8 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
int first_sack_index;
if (!tp->sacked_out) {
+ if (WARN_ON(tp->fackets_out))
+ tcp_print_queue(sk);
tp->fackets_out = 0;
tp->highest_sack = tp->snd_una;
}
@@ -1420,6 +1422,7 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
}
}
}
+ tcp_verify_fackets(sk);
/* Check for lost retransmit. This superb idea is
* borrowed from "ratehalving". Event "C".
@@ -1632,13 +1635,14 @@ void tcp_enter_frto(struct sock *sk)
tcp_set_ca_state(sk, TCP_CA_Disorder);
tp->high_seq = tp->snd_nxt;
tp->frto_counter = 1;
+ tcp_verify_fackets(sk);
}
/* Enter Loss state after F-RTO was applied. Dupack arrived after RTO,
* which indicates that we should follow the traditional RTO recovery,
* i.e. mark everything lost and do go-back-N retransmission.
*/
-static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int
flag)
+void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
@@ -1675,6 +1679,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int
allowed_segments, int flag)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->snd_cwnd = tcp_packets_in_flight(tp) + allowed_segments;
tp->snd_cwnd_cnt = 0;
@@ -1753,6 +1758,7 @@ void tcp_enter_loss(struct sock *sk, int how)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->reordering = min_t(unsigned int, tp->reordering,
sysctl_tcp_reordering);
@@ -2308,7 +2314,7 @@ static void tcp_mtup_probe_success(struct sock *sk,
struct sk_buff *skb)
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void
+void
tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2322,8 +2328,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
if (!tp->packets_out)
tp->sacked_out = 0;
- if (WARN_ON(!tp->sacked_out && tp->fackets_out))
+ if (WARN_ON(!tp->sacked_out && tp->fackets_out)) {
+ printk(KERN_ERR "TCP %d\n", tcp_is_reno(tp));
+ tcp_print_queue(sk);
tp->fackets_out = 0;
+ }
/* Now state machine starts.
* A. ECE, hence prohibit cwnd undoing, the reduction is required. */
@@ -2333,6 +2342,8 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
/* B. In all the states check for reneging SACKs. */
if (tp->sacked_out && tcp_check_sack_reneging(sk))
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
> got it !
>
> r3-06.test.meiosys.com login: WARNING: at
> /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
> tcp_fastretrans_alert()
>
> Call Trace:
>[] tcp_ack+0xcd6/0x18af
[...snip...]
>
> TCP 0
Hmm, so it's SACK then...
> I wasn't doing any particular test on n/w so it took me a while to figure
> out how I was triggering the WARNING. Apparently, this is happening when I
> run ketchup, but not always. This test machine is behind many firewall &
> routers so it might be a reason.
>
> I'm trying to get the WARNING and the tcpdump output for it but for the
> moment, it seems it's beyond my reach :/
I'm currently out of ideas where it could come from... so lets try
brute-force checking as your test case is not very high-speed... This
could hide it though... :-(
Please put the patch below on top of clean rc8-mm2 (it includes the patch
I gave you last time) and try to reproduce These counter bugs can
survive for sometime until !sacked_out condition occurs, so the patch
below tries to find that out when inconsisteny occurs for the first time
regardless of sacked_out (I also removed some statics which hopefully
reduces compiler inlining for easier reading of the output). I tried this
myself (except for verify()s in frto funcs and minor printout
modifications), didn't trigger for me.
--
i.
---
include/net/tcp.h |3 +
net/ipv4/tcp_input.c | 23 +--
net/ipv4/tcp_ipv4.c | 102 +
net/ipv4/tcp_output.c |6 ++-
4 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 991ccdc..54a0d91 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,9 @@
#include
+extern void tcp_verify_fackets(struct sock *sk);
+extern void tcp_print_queue(struct sock *sk);
+
extern struct inet_hashinfo tcp_hashinfo;
extern atomic_t tcp_orphan_count;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e22ffe7..1d7367d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1140,7 +1140,7 @@ static int tcp_check_dsack(struct tcp_sock *tp, struct
sk_buff *ack_skb,
return dup_sack;
}
-static int
+int
tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32
prior_snd_una)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1160,6 +1160,8 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
int first_sack_index;
if (!tp->sacked_out) {
+ if (WARN_ON(tp->fackets_out))
+ tcp_print_queue(sk);
tp->fackets_out = 0;
tp->highest_sack = tp->snd_una;
}
@@ -1420,6 +1422,7 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
}
}
}
+ tcp_verify_fackets(sk);
/* Check for lost retransmit. This superb idea is
* borrowed from "ratehalving". Event "C".
@@ -1632,13 +1635,14 @@ void tcp_enter_frto(struct sock *sk)
tcp_set_ca_state(sk, TCP_CA_Disorder);
tp->high_seq = tp->snd_nxt;
tp->frto_counter = 1;
+ tcp_verify_fackets(sk);
}
/* Enter Loss state after F-RTO was applied. Dupack arrived after RTO,
* which indicates that we should follow the traditional RTO recovery,
* i.e. mark everything lost and do go-back-N retransmission.
*/
-static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int
flag)
+void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
@@ -1675,6 +1679,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int
allowed_segments, int flag)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->snd_cwnd = tcp_packets_in_flight(tp) + allowed_segments;
tp->snd_cwnd_cnt = 0;
@@ -1753,6 +1758,7 @@ void tcp_enter_loss(struct sock *sk, int how)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->reordering = min_t(unsigned int, tp->reordering,
sysctl_tcp_reordering);
@@ -2308,7 +2314,7 @@ static void tcp_mtup_probe_success(struct sock *sk,
struct sk_buff *skb)
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void
+void
tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2322,8 +2328,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
if (!tp->packets_out)
tp->sacked_out = 0;
- if (WARN_ON(!tp->sacked_out && tp->
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
got it !
r3-06.test.meiosys.com login: WARNING: at
/home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
tcp_fastretrans_alert()
Call Trace:
IRQ [8040fdc3] tcp_ack+0xcd6/0x18af
[...snip...]
TCP 0
Hmm, so it's SACK then...
I wasn't doing any particular test on n/w so it took me a while to figure
out how I was triggering the WARNING. Apparently, this is happening when I
run ketchup, but not always. This test machine is behind many firewall
routers so it might be a reason.
I'm trying to get the WARNING and the tcpdump output for it but for the
moment, it seems it's beyond my reach :/
I'm currently out of ideas where it could come from... so lets try
brute-force checking as your test case is not very high-speed... This
could hide it though... :-(
Please put the patch below on top of clean rc8-mm2 (it includes the patch
I gave you last time) and try to reproduce These counter bugs can
survive for sometime until !sacked_out condition occurs, so the patch
below tries to find that out when inconsisteny occurs for the first time
regardless of sacked_out (I also removed some statics which hopefully
reduces compiler inlining for easier reading of the output). I tried this
myself (except for verify()s in frto funcs and minor printout
modifications), didn't trigger for me.
--
i.
---
include/net/tcp.h |3 +
net/ipv4/tcp_input.c | 23 +--
net/ipv4/tcp_ipv4.c | 102 +
net/ipv4/tcp_output.c |6 ++-
4 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 991ccdc..54a0d91 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,9 @@
#include linux/seq_file.h
+extern void tcp_verify_fackets(struct sock *sk);
+extern void tcp_print_queue(struct sock *sk);
+
extern struct inet_hashinfo tcp_hashinfo;
extern atomic_t tcp_orphan_count;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e22ffe7..1d7367d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1140,7 +1140,7 @@ static int tcp_check_dsack(struct tcp_sock *tp, struct
sk_buff *ack_skb,
return dup_sack;
}
-static int
+int
tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32
prior_snd_una)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1160,6 +1160,8 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
int first_sack_index;
if (!tp-sacked_out) {
+ if (WARN_ON(tp-fackets_out))
+ tcp_print_queue(sk);
tp-fackets_out = 0;
tp-highest_sack = tp-snd_una;
}
@@ -1420,6 +1422,7 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
}
}
}
+ tcp_verify_fackets(sk);
/* Check for lost retransmit. This superb idea is
* borrowed from ratehalving. Event C.
@@ -1632,13 +1635,14 @@ void tcp_enter_frto(struct sock *sk)
tcp_set_ca_state(sk, TCP_CA_Disorder);
tp-high_seq = tp-snd_nxt;
tp-frto_counter = 1;
+ tcp_verify_fackets(sk);
}
/* Enter Loss state after F-RTO was applied. Dupack arrived after RTO,
* which indicates that we should follow the traditional RTO recovery,
* i.e. mark everything lost and do go-back-N retransmission.
*/
-static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int
flag)
+void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
@@ -1675,6 +1679,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int
allowed_segments, int flag)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp-snd_cwnd = tcp_packets_in_flight(tp) + allowed_segments;
tp-snd_cwnd_cnt = 0;
@@ -1753,6 +1758,7 @@ void tcp_enter_loss(struct sock *sk, int how)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp-reordering = min_t(unsigned int, tp-reordering,
sysctl_tcp_reordering);
@@ -2308,7 +2314,7 @@ static void tcp_mtup_probe_success(struct sock *sk,
struct sk_buff *skb)
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void
+void
tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2322,8 +2328,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
if (!tp-packets_out)
tp-sacked_out = 0;
- if (WARN_ON(!tp-sacked_out tp-fackets_out))
+ if (WARN_ON(!tp-sacked_out tp-fackets_out)) {
+ printk(KERN_ERR TCP %d\n, tcp_is_reno(tp
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
I'm currently out of ideas where it could come from... so lets try
brute-force checking as your test case is not very high-speed... This
could hide it though... :-(
Please put the patch below on top of clean rc8-mm2 (it includes the patch
I gave you last time) and try to reproduce These counter bugs can
survive for sometime until !sacked_out condition occurs, so the patch
below tries to find that out when inconsisteny occurs for the first time
regardless of sacked_out (I also removed some statics which hopefully
reduces compiler inlining for easier reading of the output). I tried this
myself (except for verify()s in frto funcs and minor printout
modifications), didn't trigger for me.
In case you haven't yet get started (or it's easy enough to replace),
please use the one below instead (I forgot one counter from printout
in the last patch, which might turn out useful...).
--
i.
---
include/net/tcp.h |3 +
net/ipv4/tcp_input.c | 23 +--
net/ipv4/tcp_ipv4.c | 103 +
net/ipv4/tcp_output.c |6 ++-
4 files changed, 129 insertions(+), 6 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 991ccdc..54a0d91 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,9 @@
#include linux/seq_file.h
+extern void tcp_verify_fackets(struct sock *sk);
+extern void tcp_print_queue(struct sock *sk);
+
extern struct inet_hashinfo tcp_hashinfo;
extern atomic_t tcp_orphan_count;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e22ffe7..1d7367d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1140,7 +1140,7 @@ static int tcp_check_dsack(struct tcp_sock *tp, struct
sk_buff *ack_skb,
return dup_sack;
}
-static int
+int
tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32
prior_snd_una)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1160,6 +1160,8 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
int first_sack_index;
if (!tp-sacked_out) {
+ if (WARN_ON(tp-fackets_out))
+ tcp_print_queue(sk);
tp-fackets_out = 0;
tp-highest_sack = tp-snd_una;
}
@@ -1420,6 +1422,7 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
}
}
}
+ tcp_verify_fackets(sk);
/* Check for lost retransmit. This superb idea is
* borrowed from ratehalving. Event C.
@@ -1632,13 +1635,14 @@ void tcp_enter_frto(struct sock *sk)
tcp_set_ca_state(sk, TCP_CA_Disorder);
tp-high_seq = tp-snd_nxt;
tp-frto_counter = 1;
+ tcp_verify_fackets(sk);
}
/* Enter Loss state after F-RTO was applied. Dupack arrived after RTO,
* which indicates that we should follow the traditional RTO recovery,
* i.e. mark everything lost and do go-back-N retransmission.
*/
-static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int
flag)
+void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
@@ -1675,6 +1679,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int
allowed_segments, int flag)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp-snd_cwnd = tcp_packets_in_flight(tp) + allowed_segments;
tp-snd_cwnd_cnt = 0;
@@ -1753,6 +1758,7 @@ void tcp_enter_loss(struct sock *sk, int how)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp-reordering = min_t(unsigned int, tp-reordering,
sysctl_tcp_reordering);
@@ -2308,7 +2314,7 @@ static void tcp_mtup_probe_success(struct sock *sk,
struct sk_buff *skb)
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void
+void
tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2322,8 +2328,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
if (!tp-packets_out)
tp-sacked_out = 0;
- if (WARN_ON(!tp-sacked_out tp-fackets_out))
+ if (WARN_ON(!tp-sacked_out tp-fackets_out)) {
+ printk(KERN_ERR TCP %d\n, tcp_is_reno(tp));
+ tcp_print_queue(sk);
tp-fackets_out = 0;
+ }
/* Now state machine starts.
* A. ECE, hence prohibit cwnd undoing, the reduction is required. */
@@ -2333,6 +2342,8 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
int flag)
/* B. In all the states check for reneging SACKs. */
if (tp-sacked_out tcp_check_sack_reneging(sk))
return;
+
+
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Tue, 2 Oct 2007, Ilpo Järvinen wrote: I'm currently out of ideas where it could come from... Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after all, or in fact, two of them. I'll post patch for this tomorrow... -- i.
Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: From: Casey Schaufler [EMAIL PROTECTED] Smack is the Simplified Mandatory Access Control Kernel. Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data. I _really_ don't like what you are doing with these symlinks. For one thing, you have no exclusion between reading the list entries and modifying them. For another... WTF is filesystem making assumptions about the locations where the things are mounted? Hell, even if you override your tmp symlink, what happens if we want it in two chroot jails with different layouts? I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? No problems with absolute paths, can be used in chroot jails with whatever layouts, ditto for namespaces, etc. and both symlink and directory get created at the same time (by one name). Hell, if you keep a reference to dentry of directory in the data associated with symlink, you can simply switch nd-dentry to that, drop the old one and grab the reference to page containing label and return it via nd_set_link(). No need to play with allocations, strcat, yadda, yadda. readlink() can stuff the -d_name of the same dentry plus / plus label directly into user buffer; again, no allocations needed and works fine anywhere. - 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: 2.6.23-rc8-mm2
On Sun, 30 Sep 2007 22:01:43 +0200, "Rafael J. Wysocki" said: > On Sunday, 30 September 2007 10:50, Andrew Morton wrote: > > On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: > > > > > On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > > > > > Locks up hard at very early boot on my Dell Latitude - grub says loading > > > kernel, the screen clears, and we lock up before we get penguins. > > > > > > -rc8-mm1 was OK. I'm off to go bisect, figured I'd drop a heads-up. > > > > > > > It doesn't ring a bell, sorry. hpet-force-enable-on-ich34.patch is known > > to be bad, but it causes failure later in the boot than that. > > http://lkml.org/lkml/2007/9/27/322, perhaps? Yep, that was it - I applied that one patch on top of -rc8-mm2 and it came up without complaint. That was certainly one that would make the CPU head off into the weeds very early in boot. I need to figure how how I managed to botch the git bisect - it flagged the very last commit, when the problem was commit N-1. pgpNuwI7EGT7J.pgp Description: PGP signature
Re: 2.6.23-rc8-mm2
On Sun, 30 Sep 2007 01:50:14 PDT, Andrew Morton said: > On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: > > > On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ > > > > Locks up hard at very early boot on my Dell Latitude - grub says loading > > kernel, the screen clears, and we lock up before we get penguins. > > > > -rc8-mm1 was OK. I'm off to go bisect, figured I'd drop a heads-up. > > > > It doesn't ring a bell, sorry. hpet-force-enable-on-ich34.patch is known > to be bad, but it causes failure later in the boot than that. OK, now I'm confoozled. I built -rc8-mm2, and it bricked. Usually my first test is then using quilt to push just origin.patch, so I know if I'm needing to bisect Linus git or Andrew -mm. Starting with a clean 23-rc8, and using 'quilt push origin.patch' to just add the Linus changes *also* gets me a brick. So I did a git bisect between 23-rc8 and the first commit listed in origin.patch, and got down to this: f7f847b01571e86044dc77e03d92f43699652f8d is first bad commit commit f7f847b01571e86044dc77e03d92f43699652f8d Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed Sep 26 15:21:33 2007 -0700 (Here's the 'git bisect log': git-bisect start # good: [4942de4a0e914f205d351a81873f4f63986bcc3c] Linux 2.6.23-rc8 git-bisect good 4942de4a0e914f205d351a81873f4f63986bcc3c # bad: [f7f847b01571e86044dc77e03d92f43699652f8d] Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" git-bisect bad f7f847b01571e86044dc77e03d92f43699652f8d # good: [4d3fac08718b49fc256bdb447a479d089ca97b78] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev git-bisect good 4d3fac08718b49fc256bdb447a479d089ca97b78 # good: [d85f57938ad1d674dff8077a2e6a36a45dbe0e22] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git-bisect good d85f57938ad1d674dff8077a2e6a36a45dbe0e22 # good: [d8c4a2f9d9e7827362fd7ab0b5d9637c6af5ac5b] mv643xx_eth: duplicate methods in initializer git-bisect good d8c4a2f9d9e7827362fd7ab0b5d9637c6af5ac5b # good: [255129d1e9ca0ed3d69d5517fae3e03d7ab4b806] NLM: Fix a circular lock dependency in lockd git-bisect good 255129d1e9ca0ed3d69d5517fae3e03d7ab4b806 # good: [e66485d747505e9d960b864fc6c37f8b2afafaf0] x86-64: Disable local APIC timer use on AMD systems with C1E git-bisect good e66485d747505e9d960b864fc6c37f8b2afafaf0 # good: [df912ea4ae7233d1504fbd861ee127bd7ee5781d] xen: execve's error paths don't pin the mm before unpinning git-bisect good df912ea4ae7233d1504fbd861ee127bd7ee5781d And diffing the 2 trees (linus -git and my "origin.patch" tree shows only the following 2 differences: commit f7f847b01571e86044dc77e03d92f43699652f8d Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed Sep 26 15:21:33 2007 -0700 Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" commit 2efa33f81ef56e7700c09a3d8a881c96692149e5 Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Wed Sep 26 14:11:43 2007 -0700 [x86 setup] Handle case of improperly terminated E820 chain So I'm having a pretty good case of WTF? going at the moment... pgpcIPnnfgoO3.pgp Description: PGP signature
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
Ilpo Järvinen wrote: > On Sat, 29 Sep 2007, Cedric Le Goater wrote: > >> Ilpo Järvinen wrote: >>> On Fri, 28 Sep 2007, Ilpo Järvinen wrote: >>>> On Fri, 28 Sep 2007, Cedric Le Goater wrote: >>>> >>>>> I just found that warning in my logs. It seems that it's been >>>>> happening since rc7-mm1 at least. >>>>> >>>>> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 >>>>> tcp_fastretrans_alert() >>>>> >>>>> Call Trace: >>>>>[] tcp_ack+0xcd6/0x1894 >>>>> ...snip... >>>> ...Thanks for the report, I'll have look what could still break >>>> fackets_out... >>> I think this one is now clear to me, tcp_fragment/collapse adjusts >>> fackets_out (incorrectly) also for reno flow when there were some dupACKs >>> that made sacked_out != 0. Could you please try if patch below proves all >>> them to be of non-SACK origin... In case that's true, it's rather >>> harmless, I'll send a fix on Monday or so (this would anyway be needed)... >>> If you find out that them occur with SACK enabled flow, that would be >>> more interesting and requires more digging... >> I'm trying now to reproduce this WARNING. >> >> It seems that the n/w behaves differently during the week ends. Probably >> taking a break. > > Thanks. > > Of course there are other means too to determine if TCP flows do negotiate > SACK enabled or not. Depending on your test case (which is fully unknown > to me) they may or may not be usable... At least the value of tcp_sack > sysctl on both systems or tcpdump catching SYN packets should give that > detail. ...If you know to which hosts TCP could be connected (and active) > to, while the WARNING triggers, it's really easy to test what is being > negotiated as it's unlikely to change at short notice and any TCP flow to > that host will get us the same information though the WARNING would not be > triggered with it at this time. Obviously if at least one of the remotes > is not known or the set ends up being mixture of reno and SACK flows, then > we'll just have to wait and see which fish we get... got it ! r3-06.test.meiosys.com login: WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert() Call Trace: [] tcp_ack+0xcd6/0x18af [] tcp_rcv_established+0x61f/0x6df [] __lock_acquire+0x8a1/0xf1b [] tcp_v4_do_rcv+0x3e/0x394 [] tcp_v4_rcv+0x61c/0x9a9 [] ip_local_deliver+0x1da/0x2a4 [] ip_rcv+0x583/0x5c9 [] packet_rcv_spkt+0x19a/0x1a8 [] netif_receive_skb+0x2cf/0x2f5 [] :tg3:tg3_poll+0x65d/0x8a4 [] net_rx_action+0xb8/0x191 [] __do_softirq+0x5f/0xe0 [] call_softirq+0x1c/0x28 [] do_softirq+0x3b/0xb8 [] irq_exit+0x4e/0x50 [] do_IRQ+0xbd/0xd7 [] mwait_idle+0x0/0x4d [] ret_from_intr+0x0/0xf [] mwait_idle+0x43/0x4d [] enter_idle+0x22/0x24 [] cpu_idle+0x9d/0xc0 [] rest_init+0x55/0x57 [] start_kernel+0x2d6/0x2e2 [] _sinittext+0x134/0x13b TCP 0 I wasn't doing any particular test on n/w so it took me a while to figure out how I was triggering the WARNING. Apparently, this is happening when I run ketchup, but not always. This test machine is behind many firewall & routers so it might be a reason. tcpdump gave me this output for a wget on kernel.org : 10:51:14.835981 IP r3-06.test.meiosys.com.40322 > pub2.kernel.org.http: S 737836267:737836267(0) win 5840 10:51:14.975153 IP pub2.kernel.org.http > r3-06.test.meiosys.com.40321: F 524:524(0) ack 166 win 5840 10:51:14.975177 IP r3-06.test.meiosys.com.40321 > pub2.kernel.org.http: . ack 525 win 7504 I'm trying to get the WARNING and the tcpdump output for it but for the moment, it seems it's beyond my reach :/ Hope it helps ! C. - 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: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
Ilpo Järvinen wrote: On Sat, 29 Sep 2007, Cedric Le Goater wrote: Ilpo Järvinen wrote: On Fri, 28 Sep 2007, Ilpo Järvinen wrote: On Fri, 28 Sep 2007, Cedric Le Goater wrote: I just found that warning in my logs. It seems that it's been happening since rc7-mm1 at least. WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert() Call Trace: IRQ [8040fdc3] tcp_ack+0xcd6/0x1894 ...snip... ...Thanks for the report, I'll have look what could still break fackets_out... I think this one is now clear to me, tcp_fragment/collapse adjusts fackets_out (incorrectly) also for reno flow when there were some dupACKs that made sacked_out != 0. Could you please try if patch below proves all them to be of non-SACK origin... In case that's true, it's rather harmless, I'll send a fix on Monday or so (this would anyway be needed)... If you find out that them occur with SACK enabled flow, that would be more interesting and requires more digging... I'm trying now to reproduce this WARNING. It seems that the n/w behaves differently during the week ends. Probably taking a break. Thanks. Of course there are other means too to determine if TCP flows do negotiate SACK enabled or not. Depending on your test case (which is fully unknown to me) they may or may not be usable... At least the value of tcp_sack sysctl on both systems or tcpdump catching SYN packets should give that detail. ...If you know to which hosts TCP could be connected (and active) to, while the WARNING triggers, it's really easy to test what is being negotiated as it's unlikely to change at short notice and any TCP flow to that host will get us the same information though the WARNING would not be triggered with it at this time. Obviously if at least one of the remotes is not known or the set ends up being mixture of reno and SACK flows, then we'll just have to wait and see which fish we get... got it ! r3-06.test.meiosys.com login: WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert() Call Trace: IRQ [8040fdc3] tcp_ack+0xcd6/0x18af [80412b6f] tcp_rcv_established+0x61f/0x6df [80254146] __lock_acquire+0x8a1/0xf1b [80419d19] tcp_v4_do_rcv+0x3e/0x394 [8041a68b] tcp_v4_rcv+0x61c/0x9a9 [803ff1e3] ip_local_deliver+0x1da/0x2a4 [803ffb4e] ip_rcv+0x583/0x5c9 [8046d35b] packet_rcv_spkt+0x19a/0x1a8 [803e081c] netif_receive_skb+0x2cf/0x2f5 [88042505] :tg3:tg3_poll+0x65d/0x8a4 [803e09e8] net_rx_action+0xb8/0x191 [8023a927] __do_softirq+0x5f/0xe0 [8020c98c] call_softirq+0x1c/0x28 [8020e9c3] do_softirq+0x3b/0xb8 [8023aa1e] irq_exit+0x4e/0x50 [8020e7df] do_IRQ+0xbd/0xd7 [80209cb9] mwait_idle+0x0/0x4d [8020bce6] ret_from_intr+0x0/0xf EOI [80209cfc] mwait_idle+0x43/0x4d [802099fb] enter_idle+0x22/0x24 [80209c4f] cpu_idle+0x9d/0xc0 [80476aa1] rest_init+0x55/0x57 [80630815] start_kernel+0x2d6/0x2e2 [80630134] _sinittext+0x134/0x13b TCP 0 I wasn't doing any particular test on n/w so it took me a while to figure out how I was triggering the WARNING. Apparently, this is happening when I run ketchup, but not always. This test machine is behind many firewall routers so it might be a reason. tcpdump gave me this output for a wget on kernel.org : 10:51:14.835981 IP r3-06.test.meiosys.com.40322 pub2.kernel.org.http: S 737836267:737836267(0) win 5840 mss 1460,sackOK,timestamp 1309245 0,nop,wscale 7 10:51:14.975153 IP pub2.kernel.org.http r3-06.test.meiosys.com.40321: F 524:524(0) ack 166 win 5840 10:51:14.975177 IP r3-06.test.meiosys.com.40321 pub2.kernel.org.http: . ack 525 win 7504 I'm trying to get the WARNING and the tcpdump output for it but for the moment, it seems it's beyond my reach :/ Hope it helps ! C. - 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: 2.6.23-rc8-mm2
On Sun, 30 Sep 2007 01:50:14 PDT, Andrew Morton said: On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ Locks up hard at very early boot on my Dell Latitude - grub says loading kernel, the screen clears, and we lock up before we get penguins. -rc8-mm1 was OK. I'm off to go bisect, figured I'd drop a heads-up. It doesn't ring a bell, sorry. hpet-force-enable-on-ich34.patch is known to be bad, but it causes failure later in the boot than that. OK, now I'm confoozled. I built -rc8-mm2, and it bricked. Usually my first test is then using quilt to push just origin.patch, so I know if I'm needing to bisect Linus git or Andrew -mm. Starting with a clean 23-rc8, and using 'quilt push origin.patch' to just add the Linus changes *also* gets me a brick. So I did a git bisect between 23-rc8 and the first commit listed in origin.patch, and got down to this: f7f847b01571e86044dc77e03d92f43699652f8d is first bad commit commit f7f847b01571e86044dc77e03d92f43699652f8d Author: Linus Torvalds [EMAIL PROTECTED] Date: Wed Sep 26 15:21:33 2007 -0700 (Here's the 'git bisect log': git-bisect start # good: [4942de4a0e914f205d351a81873f4f63986bcc3c] Linux 2.6.23-rc8 git-bisect good 4942de4a0e914f205d351a81873f4f63986bcc3c # bad: [f7f847b01571e86044dc77e03d92f43699652f8d] Revert x86-64: Disable local APIC timer use on AMD systems with C1E git-bisect bad f7f847b01571e86044dc77e03d92f43699652f8d # good: [4d3fac08718b49fc256bdb447a479d089ca97b78] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev git-bisect good 4d3fac08718b49fc256bdb447a479d089ca97b78 # good: [d85f57938ad1d674dff8077a2e6a36a45dbe0e22] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git-bisect good d85f57938ad1d674dff8077a2e6a36a45dbe0e22 # good: [d8c4a2f9d9e7827362fd7ab0b5d9637c6af5ac5b] mv643xx_eth: duplicate methods in initializer git-bisect good d8c4a2f9d9e7827362fd7ab0b5d9637c6af5ac5b # good: [255129d1e9ca0ed3d69d5517fae3e03d7ab4b806] NLM: Fix a circular lock dependency in lockd git-bisect good 255129d1e9ca0ed3d69d5517fae3e03d7ab4b806 # good: [e66485d747505e9d960b864fc6c37f8b2afafaf0] x86-64: Disable local APIC timer use on AMD systems with C1E git-bisect good e66485d747505e9d960b864fc6c37f8b2afafaf0 # good: [df912ea4ae7233d1504fbd861ee127bd7ee5781d] xen: execve's error paths don't pin the mm before unpinning git-bisect good df912ea4ae7233d1504fbd861ee127bd7ee5781d And diffing the 2 trees (linus -git and my origin.patch tree shows only the following 2 differences: commit f7f847b01571e86044dc77e03d92f43699652f8d Author: Linus Torvalds [EMAIL PROTECTED] Date: Wed Sep 26 15:21:33 2007 -0700 Revert x86-64: Disable local APIC timer use on AMD systems with C1E commit 2efa33f81ef56e7700c09a3d8a881c96692149e5 Author: H. Peter Anvin [EMAIL PROTECTED] Date: Wed Sep 26 14:11:43 2007 -0700 [x86 setup] Handle case of improperly terminated E820 chain So I'm having a pretty good case of WTF? going at the moment... pgpcIPnnfgoO3.pgp Description: PGP signature
Re: 2.6.23-rc8-mm2
On Sun, 30 Sep 2007 22:01:43 +0200, Rafael J. Wysocki said: On Sunday, 30 September 2007 10:50, Andrew Morton wrote: On Sat, 29 Sep 2007 22:26:21 -0400 [EMAIL PROTECTED] wrote: On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ Locks up hard at very early boot on my Dell Latitude - grub says loading kernel, the screen clears, and we lock up before we get penguins. -rc8-mm1 was OK. I'm off to go bisect, figured I'd drop a heads-up. It doesn't ring a bell, sorry. hpet-force-enable-on-ich34.patch is known to be bad, but it causes failure later in the boot than that. http://lkml.org/lkml/2007/9/27/322, perhaps? Yep, that was it - I applied that one patch on top of -rc8-mm2 and it came up without complaint. That was certainly one that would make the CPU head off into the weeds very early in boot. I need to figure how how I managed to botch the git bisect - it flagged the very last commit, when the problem was commit N-1. pgpNuwI7EGT7J.pgp Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > > That excludes all the extra stuff in -mm and should give us a good hint > > whether HPET is really at fault. > > The system does boot with rc8 + hrt1. > > Andrew: any suggestions on how to trace the "real" culprit for the hang? Not really. Ordinarily one could move hpet-force-enable-on-ich34.patch to start-of-series, then verify that mainline+hpet-force-enable-on-ich34.patch works correctly, then just bisect all the other patches. But tht doesn't work because hpet-force-enable-on-ich34.patch has a dependency on other patches in the hrt-related patch series, and it could be that the bug which you've exposed is already in mainline anyway. If you had a minimal, standalone hpet-force-enable-on-ich34.patch against mainline then you could test that against mainline. If that also failed then you could git-bisect mainline, applying hpet-force-enable-on-ich34.patch each time (I've done that before). But this assumes that you're searching for a regression in minaline. It may never have worked. - 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: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Monday 01 October 2007, Udo A. Steinberg wrote: > On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop (FP) wrote: > FP> On Monday 01 October 2007, you wrote: > FP> > I was suggesting to download 2.6.23-rc8 and applying the -hrt > patchset FP> > at > FP> > > http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ > FP> > on top of it. > > FP> The system does boot with rc8 + hrt1. > > FP> Udo: I did see one issue during boot with this rc8 + hrt1 kernel. > FP> System is Debian unstable. > FP> Setting the system clock.. > FP> select() to /dev/rtc to wait for clock tick timed out > > Thomas and Andrew are the best people to ask about what exactly has been > merged from -hrt into -mm. Maybe they can chime in here. I agree with you for the original issue. But the /dev/rtc issue described here has *nothing* to do with mm: I saw that with pure Linus' 2.6.23-rc8 + Thomas' hrt1 on top: the combination you asked me to test. So this is an issue in "your" hrt changes. Thomas may have some suggestions, but maybe you can have a look as well? I'm of course willing to do a bisect if needed to narrow this down, but I'd like to know who I'll be talking or where I should follow up for issues in the hrt patch 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: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop (FP) wrote: FP> On Monday 01 October 2007, you wrote: FP> > I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset FP> > at FP> > http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ FP> > on top of it. FP> FP> Ah, OK. I'm afraid that was not at all clear from your previous FP> message :-/ Yeah, sorry about that. FP> During 'make oldconfig' I got a config question about "CPU idle FP> support", which does not seem to be in rc8-mm2; is that correct? I FP> answered N. Shouldn't matter either way. Answering 'Y' gives you a more sophisticated C-state governor that improves battery life. FP> The system does boot with rc8 + hrt1. Good. That seems to confirm my suspicion that the real problem is caused by something in -mm which is not in -hrt. However, I have no idea what exactly could be going wrong. FP> Andrew: any suggestions on how to trace the "real" culprit for the hang? FP> FP> FP> Udo: I did see one issue during boot with this rc8 + hrt1 kernel. FP> System is Debian unstable. FP> Setting the system clock.. FP> select() to /dev/rtc to wait for clock tick timed out Thomas and Andrew are the best people to ask about what exactly has been merged from -hrt into -mm. Maybe they can chime in here. Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Monday 01 October 2007, you wrote: > On Sun, 30 Sep 2007 23:50:29 +0200 Frans Pop (FP) wrote: > > I'm not sure what you mean. I fetched the branch I think you referred > > to [1], but when I did a merge of that on top of v2.6.23-rc8-mm2 I > > got "Already up-to-date", so AFAICT that branch is fully merged into mm > > and I'm already running with you latest code... > > I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset at > http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ > on top of it. Ah, OK. I'm afraid that was not at all clear from your previous message :-/ During 'make oldconfig' I got a config question about "CPU idle support", which does not seem to be in rc8-mm2; is that correct? I answered N. > That excludes all the extra stuff in -mm and should give us a good hint > whether HPET is really at fault. The system does boot with rc8 + hrt1. Andrew: any suggestions on how to trace the "real" culprit for the hang? Udo: I did see one issue during boot with this rc8 + hrt1 kernel. System is Debian unstable. Setting the system clock.. select() to /dev/rtc to wait for clock tick timed out Also, if the patchset really is not the same as in mm, then that at least partially invalidates this test. Relevant lines from dmesg diff: -Linux version 2.6.23-rc6 [...] +Linux version 2.6.23-rc8-hrt1 [...] [...] +hpet clockevent registered +hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 +hpet0: 3 64-bit timers, 14318180 Hz ACPI: RTC can wake from S4 Time: tsc clocksource has been installed. [...] -Marking TSC unstable due to: possible TSC halt in C2. -Time: acpi_pm clocksource has been installed. [...] -Clocksource tsc unstable (delta = -473964036 ns) [...] Real Time Clock Driver v1.12ac [...] +Marking TSC unstable due to: cpufreq changes. +Time: hpet clocksource has been installed. +Clocksource tsc unstable (delta = -125526392 ns) # cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm pit jiffies tsc # cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet I noted that acpi_pm is no longer mentioned in dmesg, but is still present. Cheers, FJP - 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: [2.6.23-rc8-mm2] Fails to resume from s2mem (was:kernel BUG at mm/slab.c:591! ...)
On Sunday 30 September 2007, you wrote: > On Sun, 30 Sep 2007 00:15:35 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > > On Friday 28 September 2007, you wrote: > > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: > > > > With 'hpet-force-enable-on-ich34' reverted the system boots OK again. > > > > We're not yet done though. It now fails to resume from suspend > > suspend-to-RAM? Can you describe this failure a bit more? The suspend is done from KDE by closing the lid, which runs a trivial script. The system seems to suspend normally (correct leds at the end). When I open the lid again, the system seems to restart (fan starts, leds change), but the LCD only shows: L System cannot be reached over the net. After some time the fans speed up. Exactly the same happens if I 'echo mem /sys/power/state' from console without X running. BTW, that partial display is normal for me: I mostly see "Linu" until the switch to X.Org, but never a full sentence that makes sense. *Is* that normal? - 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: [2.6.23-rc8-mm2] kernel BUG at mm/slab.c:591! | invalid opcode: 0000 [#1] SMP
> > +Call Trace: > > + [] kobject_cleanup+0x31/0x47 > > + [] kref_put+0x76/0x84 > > + [] fuse_sysfs_cleanup+0xa/0x14 [fuse] > > + [] fuse_exit+0x19/0x24 [fuse] > > + [] sys_delete_module+0x1c0/0x228 > > + [] sysenter_past_esp+0x6b/0xa1 > > + [] 0xe410 > > + === > > +Code: aa 43 c0 8b 02 25 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c 8b 02 25 > > 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c 8b 02 84 c0 78 04 <0f> 0b eb fe > > 8b 4a 18 64 a1 08 00 40 c0 8b 1c 81 8b 03 3b 43 04 > > +EIP: [] kfree+0x5e/0x97 SS:ESP 0068:c7205f14 > > > > I think we have now fixed that - Miklos, do you recall? Yes, Greg has a fix. I didn't see it go into -mm yet. Miklos - 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/
