* [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
@ 2012-04-02 14:27 Bruno Prémont
2012-04-02 14:50 ` Bruno Prémont
0 siblings, 1 reply; 28+ messages in thread
From: Bruno Prémont @ 2012-04-02 14:27 UTC (permalink / raw)
To: linux-kernel, Eric W. Biederman; +Cc: Greg KH, Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 8060 bytes --]
Trying to boot a freshly built 3.4-rc1 (x86_64) kernel I'm getting the following
trace (server is HP Proliant G4):
[ 0.986317] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 0.990542] IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
[ 0.993693] PGD 0
[ 0.994682] Oops: 0000 [#1] SMP
[ 0.996198] CPU 0
[ 0.996198] Modules linked in:
[ 0.996198]
[ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
[ 0.996198] RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
[ 0.996198] RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
[ 0.996198] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
[ 0.996198] RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
[ 0.996198] RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
[ 0.996198] R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
[ 0.996198] R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
[ 0.996198] FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
[ 0.996198] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 0.996198] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
[ 0.996198] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.996198] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 0.996198] Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
[ 0.996198] Stack:
[ 0.996198] ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
[ 0.996198] ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
[ 0.996198] 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
[ 0.996198] Call Trace:
[ 0.996198] [<ffffffff811527be>] sysfs_create_group+0xe/0x10
[ 0.996198] [<ffffffff81376ca6>] device_add_groups+0x46/0x80
[ 0.996198] [<ffffffff81377d3d>] device_add+0x46d/0x6a0
[ 0.996198] [<ffffffff81377891>] ? device_private_init+0x51/0x90
[ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
[ 0.996198] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
[ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
[ 0.996198] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
[ 0.996198] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
[ 0.996198] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
[ 0.996198] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
[ 0.996198] [<ffffffff815f3714>] kernel_thread_helper+0x4/0x10
[ 0.996198] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
[ 0.996198] [<ffffffff815f3710>] ? gs_change+0xb/0xb
[ 0.996198] Code: ff 85 c0 0f 85 bc 00 00 00 4c 8b 6d c8 4d 85 ed 74 15 41 8b 45 00 85 c0 0f 84 0b 01 00 00 f0 41 ff 45 00 4c 8b 6d c8 49 8b 5e 10 <48> 8b 03 48 85 c0 74 71 45 31 e4 eb 44 49 8b 46 08 48 85 c0 74
[ 0.996198] RIP [<ffffffff81152673>] internal_create_group+0x83/0x1a0
[ 0.996198] RSP <ffff88019485fd70>
[ 0.996198] CR2: 0000000000000000
[ 1.131357] ---[ end trace 319c95c486d7d9cd ]---
[ 1.133676] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[ 1.133677]
Short objdump analysis gives me:
ffffffff811525f0 <internal_create_group>:
ffffffff811525f0: 55 push %rbp
ffffffff811525f1: 48 89 e5 mov %rsp,%rbp
ffffffff811525f4: 41 57 push %r15
ffffffff811525f6: 41 89 f7 mov %esi,%r15d
ffffffff811525f9: 41 56 push %r14
ffffffff811525fb: 49 89 d6 mov %rdx,%r14
ffffffff811525fe: 41 55 push %r13
ffffffff81152600: 41 54 push %r12
ffffffff81152602: 53 push %rbx
ffffffff81152603: 48 83 ec 28 sub $0x28,%rsp
ffffffff81152607: 48 89 7d b8 mov %rdi,-0x48(%rbp)
ffffffff8115260b: 48 85 ff test %rdi,%rdi
ffffffff8115260e: 0f 84 5b 01 00 00 je ffffffff8115276f <internal_create_group+0x17f>
ffffffff81152614: 85 f6 test %esi,%esi
ffffffff81152616: 0f 84 48 01 00 00 je ffffffff81152764 <internal_create_group+0x174>
ffffffff8115261c: 48 8b 55 b8 mov -0x48(%rbp),%rdx
ffffffff81152620: b8 ea ff ff ff mov $0xffffffea,%eax
ffffffff81152625: 48 83 7a 30 00 cmpq $0x0,0x30(%rdx)
ffffffff8115262a: 0f 84 dd 00 00 00 je ffffffff8115270d <internal_create_group+0x11d>
ffffffff81152630: 49 8b 36 mov (%r14),%rsi
ffffffff81152633: 48 85 f6 test %rsi,%rsi
ffffffff81152636: 0f 84 e4 00 00 00 je ffffffff81152720 <internal_create_group+0x130>
ffffffff8115263c: 48 8d 55 c8 lea -0x38(%rbp),%rdx
ffffffff81152640: 48 8b 7d b8 mov -0x48(%rbp),%rdi
ffffffff81152644: e8 37 e9 ff ff callq ffffffff81150f80 <sysfs_create_subdir>
ffffffff81152649: 85 c0 test %eax,%eax
ffffffff8115264b: 0f 85 bc 00 00 00 jne ffffffff8115270d <internal_create_group+0x11d>
ffffffff81152651: 4c 8b 6d c8 mov -0x38(%rbp),%r13
ffffffff81152655: 4d 85 ed test %r13,%r13
ffffffff81152658: 74 15 je ffffffff8115266f <internal_create_group+0x7f>
ffffffff8115265a: 41 8b 45 00 mov 0x0(%r13),%eax
ffffffff8115265e: 85 c0 test %eax,%eax
ffffffff81152660: 0f 84 0b 01 00 00 je ffffffff81152771 <internal_create_group+0x181>
ffffffff81152666: f0 41 ff 45 00 lock incl 0x0(%r13)
ffffffff8115266b: 4c 8b 6d c8 mov -0x38(%rbp),%r13
ffffffff8115266f: 49 8b 5e 10 mov 0x10(%r14),%rbx
ffffffff81152673: 48 8b 03 mov (%rbx),%rax
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ffffffff81152676: 48 85 c0 test %rax,%rax
ffffffff81152679: 74 71 je ffffffff811526ec <internal_create_group+0xfc>
ffffffff8115267b: 45 31 e4 xor %r12d,%r12d
ffffffff8115267e: eb 44 jmp ffffffff811526c4 <internal_create_group+0xd4>
ffffffff81152680: 49 8b 46 08 mov 0x8(%r14),%rax
ffffffff81152684: 48 85 c0 test %rax,%rax
ffffffff81152687: 74 56 je ffffffff811526df <internal_create_group+0xef>
ffffffff81152689: 44 89 e2 mov %r12d,%edx
which matches (by comparing objdump with gcc -S fs/sysfs/group.c output):
static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
const struct attribute_group *grp, int update)
{
struct attribute *const* attr;
int error = 0, i;
for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
umode_t mode = 0;
/* in update mode, we're changing the permissions or
* visibility. Do this by first removing then
* re-adding (if required) the file */
if (update)
sysfs_hash_and_remove(dir_sd, NULL, (*attr)->name);
if (grp->is_visible) {
mode = grp->is_visible(kobj, *attr, i);
if (!mode)
continue;
}
error = sysfs_add_file_mode(dir_sd, *attr, SYSFS_KOBJ_ATTR,
(*attr)->mode | mode);
if (unlikely(error))
break;
}
if (error)
remove_files(dir_sd, kobj, grp);
return error;
}
I've not verified for sure, but from my understanding it must be grp->attrs that is NULL
and causes *attr test to explode.
Any immediate idea what it could be? (config attached)
Thanks,
Bruno
[-- Attachment #2: 3.4-rc1.config --]
[-- Type: text/plain, Size: 18357 bytes --]
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION="-x86_64"
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_TREE_RCU=y
CONFIG_RCU_FANOUT=64
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_MM_OWNER=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_EVENTS=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_EFI_PARTITION=y
CONFIG_BLOCK_COMPAT=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=m
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_ZONE_DMA=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_SMP=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_NO_BOOTMEM=y
CONFIG_MCORE2=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_P6_NOP=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_CC_STACKPROTECTOR=y
CONFIG_HZ_100=y
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="vga=normal slub_debug=ZP"
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ACPI=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_HED=m
CONFIG_ACPI_APEI=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_INTEL_IDLE=y
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEFAULT=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_IOAPIC=y
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_IA32_EMULATION=y
CONFIG_X86_X32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=y
CONFIG_INET=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_LRO=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_IPV6=y
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_ACCT=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CT_NETLINK=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_LOG=y
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_OWNER=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_RECENT=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_TIME=y
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_RPFILTER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_NF_DEFRAG_IPV6=y
CONFIG_NF_CONNTRACK_IPV6=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_RPFILTER=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_NETPRIO_CGROUP=y
CONFIG_BQL=y
CONFIG_HAVE_BPF_JIT=y
CONFIG_FIB_RULES=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_PNP=y
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_CPQ_CISS_DA=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_HP_ILO=y
CONFIG_HAVE_IDE=y
CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_SCSI_HPSA=y
CONFIG_LIBFC=y
CONFIG_SCSI_QLA_FC=y
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=y
CONFIG_ATA=y
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_ATA_PIIX=y
CONFIG_PATA_SERVERWORKS=y
CONFIG_PATA_ACPI=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_MULTIPATH=y
CONFIG_FUSION=y
CONFIG_FUSION_SPI=y
CONFIG_FUSION_MAX_SGE=128
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_BNX2=y
CONFIG_TIGON3=y
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E1000=y
CONFIG_E1000E=y
CONFIG_PHYLIB=y
CONFIG_BROADCOM_PHY=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=800
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=600
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_IPMI_HANDLER=y
CONFIG_IPMI_DEVICE_INTERFACE=y
CONFIG_IPMI_SI=y
CONFIG_IPMI_WATCHDOG=y
CONFIG_IPMI_POWEROFF=y
CONFIG_NVRAM=m
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_POWER_SUPPLY=y
CONFIG_HWMON=y
CONFIG_SENSORS_CORETEMP=y
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_HP_WATCHDOG=y
CONFIG_HPWDT_NMI_DECODING=y
CONFIG_SSB_POSSIBLE=y
CONFIG_BCMA_POSSIBLE=y
CONFIG_MFD_CORE=y
CONFIG_LPC_SCH=y
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=2
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_TTM=y
CONFIG_DRM_RADEON=y
CONFIG_DRM_RADEON_KMS=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=128
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_USB_HID=y
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_STORAGE=m
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_DMADEVICES=y
CONFIG_INTEL_IOATDMA=y
CONFIG_DMA_ENGINE=y
CONFIG_NET_DMA=y
CONFIG_DCA=y
CONFIG_X86_PLATFORM_DEVICES=y
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_DEFAULT_ON=y
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_DMIID=y
CONFIG_DMI_SYSFS=y
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_XFS_FS=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_GENERIC_ACL=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
CONFIG_PSTORE=y
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_RCU_CPU_STALL_TIMEOUT=60
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_SET_MODULE_RONX=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_OPTIMIZE_INLINING=y
CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_XTS=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_BLOWFISH_COMMON=y
CONFIG_CRYPTO_BLOWFISH_X86_64=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_X86_64=y
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_HW=y
CONFIG_HAVE_KVM=y
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC32_SLICEBY8=y
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 14:27 [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related? Bruno Prémont
@ 2012-04-02 14:50 ` Bruno Prémont
2012-04-02 19:01 ` Eric W. Biederman
0 siblings, 1 reply; 28+ messages in thread
From: Bruno Prémont @ 2012-04-02 14:50 UTC (permalink / raw)
To: linux-kernel; +Cc: Eric W. Biederman, Greg KH, Linus Torvalds
On Mon, 2 Apr 2012 16:27:16 Bruno Prémont wrote:
> Trying to boot a freshly built 3.4-rc1 (x86_64) kernel I'm getting the following
> trace (server is HP Proliant G4):
>
> [ 0.986317] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 0.990542] IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> [ 0.993693] PGD 0
> [ 0.994682] Oops: 0000 [#1] SMP
> [ 0.996198] CPU 0
> [ 0.996198] Modules linked in:
> [ 0.996198]
> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> [ 0.996198] RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> [ 0.996198] RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
> [ 0.996198] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
> [ 0.996198] RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
> [ 0.996198] RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
> [ 0.996198] R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
> [ 0.996198] R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
> [ 0.996198] FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
> [ 0.996198] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 0.996198] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
> [ 0.996198] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 0.996198] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 0.996198] Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
> [ 0.996198] Stack:
> [ 0.996198] ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
> [ 0.996198] ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
> [ 0.996198] 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
> [ 0.996198] Call Trace:
> [ 0.996198] [<ffffffff811527be>] sysfs_create_group+0xe/0x10
> [ 0.996198] [<ffffffff81376ca6>] device_add_groups+0x46/0x80
> [ 0.996198] [<ffffffff81377d3d>] device_add+0x46d/0x6a0
> [ 0.996198] [<ffffffff81377891>] ? device_private_init+0x51/0x90
> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 0.996198] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 0.996198] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
> [ 0.996198] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
> [ 0.996198] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
> [ 0.996198] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
> [ 0.996198] [<ffffffff815f3714>] kernel_thread_helper+0x4/0x10
> [ 0.996198] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
> [ 0.996198] [<ffffffff815f3710>] ? gs_change+0xb/0xb
> [ 0.996198] Code: ff 85 c0 0f 85 bc 00 00 00 4c 8b 6d c8 4d 85 ed 74 15 41 8b 45 00 85 c0 0f 84 0b 01 00 00 f0 41 ff 45 00 4c 8b 6d c8 49 8b 5e 10 <48> 8b 03 48 85 c0 74 71 45 31 e4 eb 44 49 8b 46 08 48 85 c0 74
> [ 0.996198] RIP [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> [ 0.996198] RSP <ffff88019485fd70>
> [ 0.996198] CR2: 0000000000000000
> [ 1.131357] ---[ end trace 319c95c486d7d9cd ]---
> [ 1.133676] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 1.133677]
The patch below works around it and leaves exactly one trace for WARN_ON() matching
above BUG.
With it, system boots to userspace.
Thanks,
Bruno
---
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index dd1701c..0040ff2 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
struct attribute *const* attr;
int error = 0, i;
- for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
+ WARN_ON(!grp->attrs);
+ for (i = 0, attr = grp->attrs; attr && *attr && !error; i++, attr++) {
umode_t mode = 0;
/* in update mode, we're changing the permissions or
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 14:50 ` Bruno Prémont
@ 2012-04-02 19:01 ` Eric W. Biederman
2012-04-02 19:34 ` Bruno Prémont
0 siblings, 1 reply; 28+ messages in thread
From: Eric W. Biederman @ 2012-04-02 19:01 UTC (permalink / raw)
To: Bruno Prémont; +Cc: linux-kernel, Greg KH, Linus Torvalds
Bruno Prémont <bonbons@linux-vserver.org> writes:
> On Mon, 2 Apr 2012 16:27:16 Bruno Prémont wrote:
>> Trying to boot a freshly built 3.4-rc1 (x86_64) kernel I'm getting the following
>> trace (server is HP Proliant G4):
>>
>> [ 0.986317] BUG: unable to handle kernel NULL pointer dereference at (null)
>> [ 0.990542] IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
>> [ 0.993693] PGD 0
>> [ 0.994682] Oops: 0000 [#1] SMP
>> [ 0.996198] CPU 0
>> [ 0.996198] Modules linked in:
>> [ 0.996198]
>> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
>> [ 0.996198] RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
>> [ 0.996198] RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
>> [ 0.996198] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
>> [ 0.996198] RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
>> [ 0.996198] RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
>> [ 0.996198] R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
>> [ 0.996198] R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
>> [ 0.996198] FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
>> [ 0.996198] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 0.996198] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
>> [ 0.996198] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 0.996198] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [ 0.996198] Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
>> [ 0.996198] Stack:
>> [ 0.996198] ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
>> [ 0.996198] ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
>> [ 0.996198] 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
>> [ 0.996198] Call Trace:
>> [ 0.996198] [<ffffffff811527be>] sysfs_create_group+0xe/0x10
>> [ 0.996198] [<ffffffff81376ca6>] device_add_groups+0x46/0x80
>> [ 0.996198] [<ffffffff81377d3d>] device_add+0x46d/0x6a0
>> [ 0.996198] [<ffffffff81377891>] ? device_private_init+0x51/0x90
>> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
>> [ 0.996198] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
>> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
>> [ 0.996198] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
>> [ 0.996198] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
>> [ 0.996198] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
>> [ 0.996198] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
>> [ 0.996198] [<ffffffff815f3714>] kernel_thread_helper+0x4/0x10
>> [ 0.996198] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
>> [ 0.996198] [<ffffffff815f3710>] ? gs_change+0xb/0xb
>> [ 0.996198] Code: ff 85 c0 0f 85 bc 00 00 00 4c 8b 6d c8 4d 85 ed 74 15 41 8b 45 00 85 c0 0f 84 0b 01 00 00 f0 41 ff 45 00 4c 8b 6d c8 49 8b 5e 10 <48> 8b 03 48 85 c0 74 71 45 31 e4 eb 44 49 8b 46 08 48 85 c0 74
>> [ 0.996198] RIP [<ffffffff81152673>] internal_create_group+0x83/0x1a0
>> [ 0.996198] RSP <ffff88019485fd70>
>> [ 0.996198] CR2: 0000000000000000
>> [ 1.131357] ---[ end trace 319c95c486d7d9cd ]---
>> [ 1.133676] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
>> [ 1.133677]
>
> The patch below works around it and leaves exactly one trace for WARN_ON() matching
> above BUG.
> With it, system boots to userspace.
>
> Thanks,
> Bruno
>
> ---
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index dd1701c..0040ff2 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
> struct attribute *const* attr;
> int error = 0, i;
>
> - for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> + WARN_ON(!grp->attrs);
> + for (i = 0, attr = grp->attrs; attr && *attr && !error; i++, attr++) {
> umode_t mode = 0;
>
> /* in update mode, we're changing the permissions or
Sysfs has not changed in this area from 3.3.
The sysctl in your backtrace looks like left over addresses on the stack.
The backtrack indicates this is something perf related going wonky.
I would suggest you try disabling your perf related options one by one
until the broken one shows up. Or possibly just initially disable perf.
This looks like one of those crazy things where something registers
with the perf subsystem, and then perf later registers it with sysfs,
and whatever was registered did not have set the needed group attrs.
Eric
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 19:01 ` Eric W. Biederman
@ 2012-04-02 19:34 ` Bruno Prémont
2012-04-02 20:04 ` David Ahern
2012-04-02 21:24 ` Peter Zijlstra
0 siblings, 2 replies; 28+ messages in thread
From: Bruno Prémont @ 2012-04-02 19:34 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, Greg KH, Linus Torvalds, Ingo Molnar, Peter Zijlstra
[adding a few perf people to CC as might originate from perf]
On Mon, 02 April 2012 Eric W. Biederman wrote:
> Bruno Prémont writes:
> > On Mon, 2 Apr 2012 16:27:16 Bruno Prémont wrote:
> >> Trying to boot a freshly built 3.4-rc1 (x86_64) kernel I'm getting the following
> >> trace (server is HP Proliant G4):
> >>
> >> [ 0.986317] BUG: unable to handle kernel NULL pointer dereference at (null)
> >> [ 0.990542] IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> >> [ 0.993693] PGD 0
> >> [ 0.994682] Oops: 0000 [#1] SMP
> >> [ 0.996198] CPU 0
> >> [ 0.996198] Modules linked in:
> >> [ 0.996198]
> >> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> >> [ 0.996198] RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> >> [ 0.996198] RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
> >> [ 0.996198] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
> >> [ 0.996198] RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
> >> [ 0.996198] RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
> >> [ 0.996198] R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
> >> [ 0.996198] R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
> >> [ 0.996198] FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
> >> [ 0.996198] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [ 0.996198] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
> >> [ 0.996198] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [ 0.996198] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [ 0.996198] Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
> >> [ 0.996198] Stack:
> >> [ 0.996198] ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
> >> [ 0.996198] ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
> >> [ 0.996198] 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
> >> [ 0.996198] Call Trace:
> >> [ 0.996198] [<ffffffff811527be>] sysfs_create_group+0xe/0x10
> >> [ 0.996198] [<ffffffff81376ca6>] device_add_groups+0x46/0x80
> >> [ 0.996198] [<ffffffff81377d3d>] device_add+0x46d/0x6a0
> >> [ 0.996198] [<ffffffff81377891>] ? device_private_init+0x51/0x90
> >> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> >> [ 0.996198] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
> >> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> >> [ 0.996198] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
> >> [ 0.996198] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
> >> [ 0.996198] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
> >> [ 0.996198] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
> >> [ 0.996198] [<ffffffff815f3714>] kernel_thread_helper+0x4/0x10
> >> [ 0.996198] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
> >> [ 0.996198] [<ffffffff815f3710>] ? gs_change+0xb/0xb
> >> [ 0.996198] Code: ff 85 c0 0f 85 bc 00 00 00 4c 8b 6d c8 4d 85 ed 74 15 41 8b 45 00 85 c0 0f 84 0b 01 00 00 f0 41 ff 45 00 4c 8b 6d c8 49 8b 5e 10 <48> 8b 03 48 85 c0 74 71 45 31 e4 eb 44 49 8b 46 08 48 85 c0 74
> >> [ 0.996198] RIP [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> >> [ 0.996198] RSP <ffff88019485fd70>
> >> [ 0.996198] CR2: 0000000000000000
> >> [ 1.131357] ---[ end trace 319c95c486d7d9cd ]---
> >> [ 1.133676] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> >> [ 1.133677]
> >
> > The patch below works around it and leaves exactly one trace for WARN_ON() matching
> > above BUG.
> > With it, system boots to userspace.
> >
> > Thanks,
> > Bruno
> >
> > ---
> > diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> > index dd1701c..0040ff2 100644
> > --- a/fs/sysfs/group.c
> > +++ b/fs/sysfs/group.c
> > @@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
> > struct attribute *const* attr;
> > int error = 0, i;
> >
> > - for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> > + WARN_ON(!grp->attrs);
> > + for (i = 0, attr = grp->attrs; attr && *attr && !error; i++, attr++) {
> > umode_t mode = 0;
> >
> > /* in update mode, we're changing the permissions or
>
> Sysfs has not changed in this area from 3.3.
>
> The sysctl in your backtrace looks like left over addresses on the stack.
>
> The backtrack indicates this is something perf related going wonky.
>
> I would suggest you try disabling your perf related options one by one
> until the broken one shows up. Or possibly just initially disable perf.
Well, I didn't enable perf, all perf-related options that are enabled
are selected by X86!
Symbol: HAVE_PERF_EVENTS [=y]
Type : boolean
Selected by: X86 [=y]
Symbol: PERF_EVENTS [=y]
Type : boolean
Prompt: Kernel performance events and counters
Defined at init/Kconfig:1157
Depends on: HAVE_PERF_EVENTS [=y]
Location:
-> General setup
-> Kernel Performance Events And Counters
Selects: ANON_INODES [=y] && IRQ_WORK [=y]
Selected by: X86 [=y] || KVM [=n] && VIRTUALIZATION [=n] && HAVE_KVM [=y] && PCI [=y] && NET [=y]
Symbol: HAVE_PERF_EVENTS_NMI [=y]
Type : boolean
Selected by: X86 [=y]
> This looks like one of those crazy things where something registers
> with the perf subsystem, and then perf later registers it with sysfs,
> and whatever was registered did not have set the needed group attrs.
>From quick-reading kernel/events/core.c which contains perf_event_sysfs_init()
and pmu_dev_alloc() and commits from v3.3..v3.4 for that file
commit 0c9d42ed4cee2aa1dfc3a260b741baae8615744f (perf, x86: Provide means
for disabling userspace RDPMC) by Peter looks like a possible
candidate or at least startpoint:
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 05affc3..dcd4049 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5505,6 +5505,7 @@ static int pmu_dev_alloc(struct pmu *pmu)
if (!pmu->dev)
goto out;
+ pmu->dev->groups = pmu->attr_groups;
device_initialize(pmu->dev);
ret = dev_set_name(pmu->dev, "%s", pmu->name);
if (ret)
Will try bisecting corresponding merge tomorrow when I have full access to affected
system.
Thanks,
Bruno
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 19:34 ` Bruno Prémont
@ 2012-04-02 20:04 ` David Ahern
2012-04-03 8:30 ` Jiri Olsa
2012-04-02 21:24 ` Peter Zijlstra
1 sibling, 1 reply; 28+ messages in thread
From: David Ahern @ 2012-04-02 20:04 UTC (permalink / raw)
To: Bruno Prémont, Jiri Olsa
Cc: Eric W. Biederman, linux-kernel, Greg KH, Linus Torvalds,
Ingo Molnar, Peter Zijlstra
On 4/2/12 1:34 PM, Bruno Prémont wrote:
> [adding a few perf people to CC as might originate from perf]
>
> On Mon, 02 April 2012 Eric W. Biederman wrote:
>> Bruno Prémont writes:
>>> On Mon, 2 Apr 2012 16:27:16 Bruno Prémont wrote:
>>>> Trying to boot a freshly built 3.4-rc1 (x86_64) kernel I'm getting the following
>>>> trace (server is HP Proliant G4):
>>>>
>>>> [ 0.986317] BUG: unable to handle kernel NULL pointer dereference at (null)
>>>> [ 0.990542] IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
>>>> [ 0.993693] PGD 0
>>>> [ 0.994682] Oops: 0000 [#1] SMP
>>>> [ 0.996198] CPU 0
>>>> [ 0.996198] Modules linked in:
>>>> [ 0.996198]
>>>> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
>>>> [ 0.996198] RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
>>>> [ 0.996198] RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
>>>> [ 0.996198] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
>>>> [ 0.996198] RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
>>>> [ 0.996198] RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
>>>> [ 0.996198] R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
>>>> [ 0.996198] R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
>>>> [ 0.996198] FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
>>>> [ 0.996198] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>> [ 0.996198] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
>>>> [ 0.996198] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> [ 0.996198] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>>> [ 0.996198] Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
>>>> [ 0.996198] Stack:
>>>> [ 0.996198] ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
>>>> [ 0.996198] ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
>>>> [ 0.996198] 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
>>>> [ 0.996198] Call Trace:
>>>> [ 0.996198] [<ffffffff811527be>] sysfs_create_group+0xe/0x10
>>>> [ 0.996198] [<ffffffff81376ca6>] device_add_groups+0x46/0x80
>>>> [ 0.996198] [<ffffffff81377d3d>] device_add+0x46d/0x6a0
>>>> [ 0.996198] [<ffffffff81377891>] ? device_private_init+0x51/0x90
>>>> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
>>>> [ 0.996198] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
>>>> [ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
>>>> [ 0.996198] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
>>>> [ 0.996198] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
>>>> [ 0.996198] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
>>>> [ 0.996198] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
>>>> [ 0.996198] [<ffffffff815f3714>] kernel_thread_helper+0x4/0x10
>>>> [ 0.996198] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
>>>> [ 0.996198] [<ffffffff815f3710>] ? gs_change+0xb/0xb
>>>> [ 0.996198] Code: ff 85 c0 0f 85 bc 00 00 00 4c 8b 6d c8 4d 85 ed 74 15 41 8b 45 00 85 c0 0f 84 0b 01 00 00 f0 41 ff 45 00 4c 8b 6d c8 49 8b 5e 10<48> 8b 03 48 85 c0 74 71 45 31 e4 eb 44 49 8b 46 08 48 85 c0 74
>>>> [ 0.996198] RIP [<ffffffff81152673>] internal_create_group+0x83/0x1a0
>>>> [ 0.996198] RSP<ffff88019485fd70>
>>>> [ 0.996198] CR2: 0000000000000000
>>>> [ 1.131357] ---[ end trace 319c95c486d7d9cd ]---
>>>> [ 1.133676] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
>>>> [ 1.133677]
>>>
>>> The patch below works around it and leaves exactly one trace for WARN_ON() matching
>>> above BUG.
>>> With it, system boots to userspace.
>>>
>>> Thanks,
>>> Bruno
>>>
>>> ---
>>> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
>>> index dd1701c..0040ff2 100644
>>> --- a/fs/sysfs/group.c
>>> +++ b/fs/sysfs/group.c
>>> @@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
>>> struct attribute *const* attr;
>>> int error = 0, i;
>>>
>>> - for (i = 0, attr = grp->attrs; *attr&& !error; i++, attr++) {
>>> + WARN_ON(!grp->attrs);
>>> + for (i = 0, attr = grp->attrs; attr&& *attr&& !error; i++, attr++) {
>>> umode_t mode = 0;
>>>
>>> /* in update mode, we're changing the permissions or
>>
>> Sysfs has not changed in this area from 3.3.
>>
>> The sysctl in your backtrace looks like left over addresses on the stack.
>>
>> The backtrack indicates this is something perf related going wonky.
>>
>> I would suggest you try disabling your perf related options one by one
>> until the broken one shows up. Or possibly just initially disable perf.
>
> Well, I didn't enable perf, all perf-related options that are enabled
> are selected by X86!
>
> Symbol: HAVE_PERF_EVENTS [=y]
> Type : boolean
> Selected by: X86 [=y]
>
> Symbol: PERF_EVENTS [=y]
> Type : boolean
> Prompt: Kernel performance events and counters
> Defined at init/Kconfig:1157
> Depends on: HAVE_PERF_EVENTS [=y]
> Location:
> -> General setup
> -> Kernel Performance Events And Counters
> Selects: ANON_INODES [=y]&& IRQ_WORK [=y]
> Selected by: X86 [=y] || KVM [=n]&& VIRTUALIZATION [=n]&& HAVE_KVM [=y]&& PCI [=y]&& NET [=y]
>
> Symbol: HAVE_PERF_EVENTS_NMI [=y]
> Type : boolean
> Selected by: X86 [=y]
>
>> This looks like one of those crazy things where something registers
>> with the perf subsystem, and then perf later registers it with sysfs,
>> and whatever was registered did not have set the needed group attrs.
>
>
> From quick-reading kernel/events/core.c which contains perf_event_sysfs_init()
> and pmu_dev_alloc() and commits from v3.3..v3.4 for that file
> commit 0c9d42ed4cee2aa1dfc3a260b741baae8615744f (perf, x86: Provide means
> for disabling userspace RDPMC) by Peter looks like a possible
> candidate or at least startpoint:
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 05affc3..dcd4049 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5505,6 +5505,7 @@ static int pmu_dev_alloc(struct pmu *pmu)
> if (!pmu->dev)
> goto out;
>
> + pmu->dev->groups = pmu->attr_groups;
> device_initialize(pmu->dev);
> ret = dev_set_name(pmu->dev, "%s", pmu->name);
> if (ret)
>
> Will try bisecting corresponding merge tomorrow when I have full access to affected
> system.
Perhaps:
641cc93 perf: Adding sysfs group format attribute for pmu device
David
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 19:34 ` Bruno Prémont
2012-04-02 20:04 ` David Ahern
@ 2012-04-02 21:24 ` Peter Zijlstra
2012-04-02 21:46 ` Peter Zijlstra
1 sibling, 1 reply; 28+ messages in thread
From: Peter Zijlstra @ 2012-04-02 21:24 UTC (permalink / raw)
To: Bruno Prémont
Cc: Eric W. Biederman, linux-kernel, Greg KH, Linus Torvalds, Ingo Molnar
On Mon, 2012-04-02 at 21:34 +0200, Bruno Prémont wrote:
> > >> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
Is this a netburst based space heater?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 21:24 ` Peter Zijlstra
@ 2012-04-02 21:46 ` Peter Zijlstra
2012-04-03 5:38 ` Bruno Prémont
2012-04-03 6:02 ` Ingo Molnar
0 siblings, 2 replies; 28+ messages in thread
From: Peter Zijlstra @ 2012-04-02 21:46 UTC (permalink / raw)
To: Bruno Prémont
Cc: Eric W. Biederman, linux-kernel, Greg KH, Linus Torvalds, Ingo Molnar
On Mon, 2012-04-02 at 23:24 +0200, Peter Zijlstra wrote:
> On Mon, 2012-04-02 at 21:34 +0200, Bruno Prémont wrote:
> > > >> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
>
> Is this a netburst based space heater?
In particular, does: https://lkml.org/lkml/2012/3/27/182 , sort it?
Ingo, could you pick that one up and route it Linus wards?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 21:46 ` Peter Zijlstra
@ 2012-04-03 5:38 ` Bruno Prémont
2012-04-03 6:02 ` Ingo Molnar
1 sibling, 0 replies; 28+ messages in thread
From: Bruno Prémont @ 2012-04-03 5:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Eric W. Biederman, linux-kernel, Greg KH, Linus Torvalds, Ingo Molnar
On Mon, 02 Apr 2012 23:46:33 Peter Zijlstra wrote:
> On Mon, 2012-04-02 at 23:24 +0200, Peter Zijlstra wrote:
> > On Mon, 2012-04-02 at 21:34 +0200, Bruno Prémont wrote:
> > > > >> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> >
> > Is this a netburst based space heater?
>
> In particular, does: https://lkml.org/lkml/2012/3/27/182 , sort it?
>
> Ingo, could you pick that one up and route it Linus wards?
It does sort it!
Tested-By: Bruno Prémont <bonbons@linux-vserver.org>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 21:46 ` Peter Zijlstra
2012-04-03 5:38 ` Bruno Prémont
@ 2012-04-03 6:02 ` Ingo Molnar
2012-04-03 6:17 ` [PATCH] Prevent crash on missing sysfs attribute group Bruno Prémont
1 sibling, 1 reply; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 6:02 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Bruno Prémont, Eric W. Biederman, linux-kernel, Greg KH,
Linus Torvalds
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2012-04-02 at 23:24 +0200, Peter Zijlstra wrote:
> > On Mon, 2012-04-02 at 21:34 +0200, Bruno Prémont wrote:
> > > > >> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> >
> > Is this a netburst based space heater?
>
> In particular, does: https://lkml.org/lkml/2012/3/27/182 , sort it?
>
> Ingo, could you pick that one up and route it Linus wards?
Will do - but the underlying generic bug should be fixed as
well: we must not crash just because some attributes are missing
in a rarely used sub-driver ...
We should WARN_ON(), etc. - but not crash.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 6:02 ` Ingo Molnar
@ 2012-04-03 6:17 ` Bruno Prémont
2012-04-03 6:31 ` Ingo Molnar
2012-04-03 7:11 ` Eric W. Biederman
0 siblings, 2 replies; 28+ messages in thread
From: Bruno Prémont @ 2012-04-03 6:17 UTC (permalink / raw)
To: Ingo Molnar, Greg KH
Cc: Peter Zijlstra, Eric W. Biederman, linux-kernel, Linus Torvalds
Prevent kernel from crashing when a device is being registered with sysfs
but has no (aka NULL) group attributes, but warn about it so calling path
can get fixed.
This would warn instead of trying NULL pointer deref like:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
PGD 0
Oops: 0000 [#1] SMP
CPU 0
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
Stack:
ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
Call Trace:
[<ffffffff811527be>] sysfs_create_group+0xe/0x10
[<ffffffff81376ca6>] device_add_groups+0x46/0x80
[<ffffffff81377d3d>] device_add+0x46d/0x6a0
...
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
---
On Tue, 3 Apr 2012 08:02:52 +0200 Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Mon, 2012-04-02 at 23:24 +0200, Peter Zijlstra wrote:
> > > On Mon, 2012-04-02 at 21:34 +0200, Bruno Prémont wrote:
> > > > > >> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> > >
> > > Is this a netburst based space heater?
> >
> > In particular, does: https://lkml.org/lkml/2012/3/27/182 , sort it?
> >
> > Ingo, could you pick that one up and route it Linus wards?
>
> Will do - but the underlying generic bug should be fixed as
> well: we must not crash just because some attributes are missing
> in a rarely used sub-driver ...
>
> We should WARN_ON(), etc. - but not crash.
Greg, is this ok for you or should the check be moved out to calling
internal_create_group()?
---
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index dd1701c..0040ff2 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
struct attribute *const* attr;
int error = 0, i;
- for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
+ WARN_ON(!grp->attrs);
+ for (i = 0, attr = grp->attrs; attr && *attr && !error; i++, attr++) {
umode_t mode = 0;
/* in update mode, we're changing the permissions or
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 6:17 ` [PATCH] Prevent crash on missing sysfs attribute group Bruno Prémont
@ 2012-04-03 6:31 ` Ingo Molnar
2012-04-03 7:11 ` Eric W. Biederman
1 sibling, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 6:31 UTC (permalink / raw)
To: Bruno Prémont
Cc: Greg KH, Peter Zijlstra, Eric W. Biederman, linux-kernel, Linus Torvalds
* Bruno Prémont <bonbons@linux-vserver.org> wrote:
> Prevent kernel from crashing when a device is being registered with sysfs
> but has no (aka NULL) group attributes, but warn about it so calling path
> can get fixed.
>
> This would warn instead of trying NULL pointer deref like:
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> PGD 0
> Oops: 0000 [#1] SMP
> CPU 0
> Modules linked in:
>
> Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
> RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
> RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
> R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
> Stack:
> ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
> ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
> 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
> Call Trace:
> [<ffffffff811527be>] sysfs_create_group+0xe/0x10
> [<ffffffff81376ca6>] device_add_groups+0x46/0x80
> [<ffffffff81377d3d>] device_add+0x46d/0x6a0
> ...
>
> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
> ---
> On Tue, 3 Apr 2012 08:02:52 +0200 Ingo Molnar wrote:
> > * Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Mon, 2012-04-02 at 23:24 +0200, Peter Zijlstra wrote:
> > > > On Mon, 2012-04-02 at 21:34 +0200, Bruno Prémont wrote:
> > > > > > >> [ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> > > >
> > > > Is this a netburst based space heater?
> > >
> > > In particular, does: https://lkml.org/lkml/2012/3/27/182 , sort it?
> > >
> > > Ingo, could you pick that one up and route it Linus wards?
> >
> > Will do - but the underlying generic bug should be fixed as
> > well: we must not crash just because some attributes are missing
> > in a rarely used sub-driver ...
> >
> > We should WARN_ON(), etc. - but not crash.
>
> Greg, is this ok for you or should the check be moved out to calling
> internal_create_group()?
>
> ---
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index dd1701c..0040ff2 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
> struct attribute *const* attr;
> int error = 0, i;
>
> - for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> + WARN_ON(!grp->attrs);
> + for (i = 0, attr = grp->attrs; attr && *attr && !error; i++, attr++) {
> umode_t mode = 0;
yeah.
Acked-by: Ingo Molnar <mingo@elte.hu>
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 6:17 ` [PATCH] Prevent crash on missing sysfs attribute group Bruno Prémont
2012-04-03 6:31 ` Ingo Molnar
@ 2012-04-03 7:11 ` Eric W. Biederman
2012-04-03 7:15 ` Ingo Molnar
1 sibling, 1 reply; 28+ messages in thread
From: Eric W. Biederman @ 2012-04-03 7:11 UTC (permalink / raw)
To: Bruno Prémont
Cc: Ingo Molnar, Greg KH, Peter Zijlstra, linux-kernel, Linus Torvalds
Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Bruno Prémont <bonbons@linux-vserver.org> writes:
> Prevent kernel from crashing when a device is being registered with sysfs
> but has no (aka NULL) group attributes, but warn about it so calling path
> can get fixed.
The idea is reasonable but the implementation is horrible.
>> Will do - but the underlying generic bug should be fixed as
>> well: we must not crash just because some attributes are missing
>> in a rarely used sub-driver ...
>>
>> We should WARN_ON(), etc. - but not crash.
FIX perf to include sanity checks.
Anything we do in sysfs is just pointless because perf was clever and
the offender did not show up in the backtrace.
Right now perf is so bad we just waste everyone's time.
> Greg, is this ok for you or should the check be moved out to calling
> internal_create_group()?
Please put changes in internal_create_group where all of the rest of the
checks are.
We should do something like:
if (!grp->attrs) {
WARN(1, "sysfs: idiot subsystem did not include attrs for group: %s/%s\n"
kobj->name, grp->name?"":grp->name);
return -EINVAL;
}
As it stands your patch is horrible it leaves sysfs in an inconsistent
state. Creating the directory and leaving it there. Not returning an
error code. It looks like there are all kinds of weird problems that
removing the group or updating the group could get into if we go with
your patch.
Eric
> ---
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index dd1701c..0040ff2 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
> struct attribute *const* attr;
> int error = 0, i;
>
> - for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> + WARN_ON(!grp->attrs);
> + for (i = 0, attr = grp->attrs; attr && *attr && !error; i++, attr++) {
> umode_t mode = 0;
>
> /* in update mode, we're changing the permissions or
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 7:11 ` Eric W. Biederman
@ 2012-04-03 7:15 ` Ingo Molnar
2012-04-03 7:41 ` [PATCH v2] Prevent crash on unset sysfs group attributes Bruno Prémont
2012-04-03 7:50 ` [PATCH] Prevent crash on missing sysfs attribute group Eric W. Biederman
0 siblings, 2 replies; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 7:15 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Bruno Prémont, Greg KH, Peter Zijlstra, linux-kernel,
Linus Torvalds
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Bruno Prémont <bonbons@linux-vserver.org> writes:
>
> > Prevent kernel from crashing when a device is being registered with sysfs
> > but has no (aka NULL) group attributes, but warn about it so calling path
> > can get fixed.
>
> The idea is reasonable but the implementation is horrible.
>
> >> Will do - but the underlying generic bug should be fixed as
> >> well: we must not crash just because some attributes are missing
> >> in a rarely used sub-driver ...
> >>
> >> We should WARN_ON(), etc. - but not crash.
>
> FIX perf to include sanity checks.
Huh, so put repeated, duplicated, inconsistently applied sanity
checks into dozens of sysfs attribute using kernel subsystems?
Major FAIL, dude.
> Anything we do in sysfs is just pointless because perf was
> clever and the offender did not show up in the backtrace.
>
> Right now perf is so bad we just waste everyone's time.
>
> > Greg, is this ok for you or should the check be moved out to
> > calling internal_create_group()?
>
> Please put changes in internal_create_group where all of the
> rest of the checks are.
So you *do* agree that a check in a generic place is useful
after all? ;-)
> We should do something like:
> if (!grp->attrs) {
> WARN(1, "sysfs: idiot subsystem did not include attrs for group: %s/%s\n"
> kobj->name, grp->name?"":grp->name);
> return -EINVAL;
> }
>
> As it stands your patch is horrible it leaves sysfs in an
> inconsistent state. Creating the directory and leaving it
> there. Not returning an error code. It looks like there are
> all kinds of weird problems that removing the group or
> updating the group could get into if we go with your patch.
This is actually a sensible suggestion. Bruno, mind updating
your patch to do something like this? Assuming Greg agrees with
putting the check/warning there.
Eric's rant about putting sanit checks at every usage site is
just crazy talk.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2] Prevent crash on unset sysfs group attributes
2012-04-03 7:15 ` Ingo Molnar
@ 2012-04-03 7:41 ` Bruno Prémont
2012-04-03 7:51 ` Eric W. Biederman
` (2 more replies)
2012-04-03 7:50 ` [PATCH] Prevent crash on missing sysfs attribute group Eric W. Biederman
1 sibling, 3 replies; 28+ messages in thread
From: Bruno Prémont @ 2012-04-03 7:41 UTC (permalink / raw)
To: Ingo Molnar
Cc: Eric W. Biederman, Greg KH, Peter Zijlstra, linux-kernel, Linus Torvalds
Do not let the kernel crash when a device is registered with
sysfs while group attributes are not set (aka NULL).
Warn about the offender with some information about the offending
device.
This would warn instead of trying NULL pointer deref like:
BUG: unable to handle kernel NULL pointer dereference at
(null) IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
PGD 0
Oops: 0000 [#1] SMP
CPU 0
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant
DL360 G4 RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>]
internal_create_group+0x83/0x1a0 RSP: 0018:ffff88019485fd70 EFLAGS:
00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX:
0000000000000001 RDX: ffff880192e99908 RSI: ffff880192e99630 RDI:
ffffffff81a26c60 RBP: ffff88019485fdc0 R08: 0000000000000000 R09:
0000000000000000 R10: ffff880192e99908 R11: 0000000000000000 R12:
ffffffff81a16a00 R13: ffff880192e99908 R14: ffffffff81a16900 R15:
0000000000000000 FS: 0000000000000000(0000) GS:ffff88019bc00000(0000)
knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b CR2: 0000000000000000 CR3: 0000000001a0c000 CR4:
00000000000007f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400 Process swapper/0 (pid: 1, threadinfo
ffff88019485e000, task ffff880194878000) Stack:
ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
Call Trace:
[<ffffffff811527be>] sysfs_create_group+0xe/0x10
[<ffffffff81376ca6>] device_add_groups+0x46/0x80
[<ffffffff81377d3d>] device_add+0x46d/0x6a0
...
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
---
On Tue, 3 Apr 2012 09:15:43 Ingo Molnar wrote:
> > > Greg, is this ok for you or should the check be moved out to
> > > calling internal_create_group()?
> >
> > Please put changes in internal_create_group where all of the
> > rest of the checks are.
>
> So you *do* agree that a check in a generic place is useful
> after all? ;-)
>
> > We should do something like:
> > if (!grp->attrs) {
> > WARN(1, "sysfs: idiot subsystem did not include attrs for group: %s/%s\n"
> > kobj->name, grp->name?"":grp->name);
> > return -EINVAL;
> > }
> >
> > As it stands your patch is horrible it leaves sysfs in an
> > inconsistent state. Creating the directory and leaving it
> > there. Not returning an error code. It looks like there are
> > all kinds of weird problems that removing the group or
> > updating the group could get into if we go with your patch.
>
> This is actually a sensible suggestion. Bruno, mind updating
> your patch to do something like this? Assuming Greg agrees with
> putting the check/warning there.
Here come a respin with Eric's suggestion.
In my case it would show the following result:
[ 0.975025] ------------[ cut here ]------------
[ 0.977507] WARNING: at /data/kernel/linux-2.6-git/fs/sysfs/group.c:72 internal_create_group+0x18c/0x1f0()
[ 0.981932] Hardware name: ProLiant DL360 G4
[ 0.983916] sysfs: attrs not set by subsystem for group: cpu/
[ 0.987030] Modules linked in:
[ 0.988664] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #6
[ 0.991639] Call Trace:
[ 0.992911] [<ffffffff8104d11a>] warn_slowpath_common+0x7a/0xb0
[ 0.995903] [<ffffffff8104d1f1>] warn_slowpath_fmt+0x41/0x50
[ 0.998593] [<ffffffff8115277c>] internal_create_group+0x18c/0x1f0
[ 1.001366] [<ffffffff8115280e>] sysfs_create_group+0xe/0x10
[ 1.003898] [<ffffffff81376cf6>] device_add_groups+0x46/0x80
[ 1.006955] [<ffffffff81377d8d>] device_add+0x46d/0x6a0
[ 1.009565] [<ffffffff813778e1>] ? device_private_init+0x51/0x90
[ 1.012806] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
[ 1.015866] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
[ 1.018234] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
[ 1.021408] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
[ 1.025517] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
[ 1.029102] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
[ 1.031844] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
[ 1.034571] [<ffffffff815f3794>] kernel_thread_helper+0x4/0x10
[ 1.037734] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
[ 1.040790] [<ffffffff815f3790>] ? gs_change+0xb/0xb
[ 1.043354] ---[ end trace 319c95c486d7d9cd ]---
[ 1.045536] ------------[ cut here ]------------
[ 1.047640] WARNING: at /data/kernel/linux-2.6-git/kernel/events/core.c:7144 perf_event_sysfs_init+0x70/0x9a()
[ 1.052595] Hardware name: ProLiant DL360 G4
[ 1.055027] Failed to register pmu: cpu, reason -22
[ 1.057720] Modules linked in:
[ 1.059284] Pid: 1, comm: swapper/0 Tainted: G W 3.4.0-rc1-x86_64 #6
[ 1.062785] Call Trace:
[ 1.064094] [<ffffffff8104d11a>] warn_slowpath_common+0x7a/0xb0
[ 1.067192] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
[ 1.070305] [<ffffffff8104d1f1>] warn_slowpath_fmt+0x41/0x50
[ 1.073129] [<ffffffff810a7244>] ? pmu_dev_alloc+0xb4/0xe0
[ 1.075771] [<ffffffff81a989e5>] perf_event_sysfs_init+0x70/0x9a
[ 1.078878] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
[ 1.081879] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
[ 1.084714] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
[ 1.087754] [<ffffffff815f3794>] kernel_thread_helper+0x4/0x10
[ 1.090639] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
[ 1.093372] [<ffffffff815f3790>] ? gs_change+0xb/0xb
[ 1.096312] ---[ end trace 319c95c486d7d9ce ]---
fs/sysfs/group.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index dd1701c..2df555c 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -67,7 +67,11 @@ static int internal_create_group(struct kobject *kobj, int update,
/* Updates may happen before the object has been instantiated */
if (unlikely(update && !kobj->sd))
return -EINVAL;
-
+ if (!grp->attrs) {
+ WARN(1, "sysfs: attrs not set by subsystem for group: %s/%s\n",
+ kobj->name, grp->name ? "" : grp->name);
+ return -EINVAL;
+ }
if (grp->name) {
error = sysfs_create_subdir(kobj, grp->name, &sd);
if (error)
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 7:15 ` Ingo Molnar
2012-04-03 7:41 ` [PATCH v2] Prevent crash on unset sysfs group attributes Bruno Prémont
@ 2012-04-03 7:50 ` Eric W. Biederman
2012-04-03 8:04 ` Ingo Molnar
2012-04-03 14:27 ` Peter Zijlstra
1 sibling, 2 replies; 28+ messages in thread
From: Eric W. Biederman @ 2012-04-03 7:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Bruno Prémont, Greg KH, Peter Zijlstra, linux-kernel,
Linus Torvalds
Ingo Molnar <mingo@kernel.org> writes:
> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> Bruno Prémont <bonbons@linux-vserver.org> writes:
>>
>> > Prevent kernel from crashing when a device is being registered with sysfs
>> > but has no (aka NULL) group attributes, but warn about it so calling path
>> > can get fixed.
>>
>> The idea is reasonable but the implementation is horrible.
>>
>> >> Will do - but the underlying generic bug should be fixed as
>> >> well: we must not crash just because some attributes are missing
>> >> in a rarely used sub-driver ...
>> >>
>> >> We should WARN_ON(), etc. - but not crash.
>>
>> FIX perf to include sanity checks.
>
> Huh, so put repeated, duplicated, inconsistently applied sanity
> checks into dozens of sysfs attribute using kernel subsystems?
>
> Major FAIL, dude.
> Eric's rant about putting sanit checks at every usage site is
> just crazy talk.
No. I was not talking about every usage site. I was talking about the
sites that are don't have a direct call chain to the sysfs methods and
instead do something clever that makes backtraces worthless.
In the normal case sysfs registration problems are simple to trace
back to their source because the backtrace points a finger at
the piece of code that when registering had a problem.
Unfortunately perf is built differently. perf seems to be built to hide
who the idiot was who registered the wrong piece of code and despite
having a perfectly good backtrace and knowing it was perf the person
reporting the original bug still was going to need to do a bisect to
find the real culprit of the problem.
So I am asking that since perf is built in a way that actively makes
debugging these kinds of problems hard that you please add additional
debugging code to perf_pmu_register or some other better location so
that simply registering something buggy with perf will show the bug.
Either that or please fix perf events so that a backtrace is worth
something.
Thanks,
Eric
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v2] Prevent crash on unset sysfs group attributes
2012-04-03 7:41 ` [PATCH v2] Prevent crash on unset sysfs group attributes Bruno Prémont
@ 2012-04-03 7:51 ` Eric W. Biederman
2012-04-03 7:53 ` Ingo Molnar
2012-04-03 7:59 ` [PATCH v2a] sysfs: " Bruno Prémont
2 siblings, 0 replies; 28+ messages in thread
From: Eric W. Biederman @ 2012-04-03 7:51 UTC (permalink / raw)
To: Bruno Prémont
Cc: Ingo Molnar, Greg KH, Peter Zijlstra, linux-kernel, Linus Torvalds
Bruno Prémont <bonbons@linux-vserver.org> writes:
> Do not let the kernel crash when a device is registered with
> sysfs while group attributes are not set (aka NULL).
>
> Warn about the offender with some information about the offending
> device.
>
> This would warn instead of trying NULL pointer deref like:
> BUG: unable to handle kernel NULL pointer dereference at
> (null) IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> PGD 0
> Oops: 0000 [#1] SMP
> CPU 0
> Modules linked in:
>
> Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant
> DL360 G4 RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>]
> internal_create_group+0x83/0x1a0 RSP: 0018:ffff88019485fd70 EFLAGS:
> 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX:
> 0000000000000001 RDX: ffff880192e99908 RSI: ffff880192e99630 RDI:
> ffffffff81a26c60 RBP: ffff88019485fdc0 R08: 0000000000000000 R09:
> 0000000000000000 R10: ffff880192e99908 R11: 0000000000000000 R12:
> ffffffff81a16a00 R13: ffff880192e99908 R14: ffffffff81a16900 R15:
> 0000000000000000 FS: 0000000000000000(0000) GS:ffff88019bc00000(0000)
> knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
> 000000008005003b CR2: 0000000000000000 CR3: 0000000001a0c000 CR4:
> 00000000000007f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400 Process swapper/0 (pid: 1, threadinfo
> ffff88019485e000, task ffff880194878000) Stack:
> ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
> ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
> 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
> Call Trace:
> [<ffffffff811527be>] sysfs_create_group+0xe/0x10
> [<ffffffff81376ca6>] device_add_groups+0x46/0x80
> [<ffffffff81377d3d>] device_add+0x46d/0x6a0
> ...
>
> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
> ---
>
> On Tue, 3 Apr 2012 09:15:43 Ingo Molnar wrote:
>> > > Greg, is this ok for you or should the check be moved out to
>> > > calling internal_create_group()?
>> >
>> > Please put changes in internal_create_group where all of the
>> > rest of the checks are.
>>
>> So you *do* agree that a check in a generic place is useful
>> after all? ;-)
>>
>> > We should do something like:
>> > if (!grp->attrs) {
>> > WARN(1, "sysfs: idiot subsystem did not include attrs for group: %s/%s\n"
>> > kobj->name, grp->name?"":grp->name);
>> > return -EINVAL;
>> > }
>> >
>> > As it stands your patch is horrible it leaves sysfs in an
>> > inconsistent state. Creating the directory and leaving it
>> > there. Not returning an error code. It looks like there are
>> > all kinds of weird problems that removing the group or
>> > updating the group could get into if we go with your patch.
>>
>> This is actually a sensible suggestion. Bruno, mind updating
>> your patch to do something like this? Assuming Greg agrees with
>> putting the check/warning there.
>
> Here come a respin with Eric's suggestion.
>
> In my case it would show the following result:
>
> [ 0.975025] ------------[ cut here ]------------
> [ 0.977507] WARNING: at /data/kernel/linux-2.6-git/fs/sysfs/group.c:72 internal_create_group+0x18c/0x1f0()
> [ 0.981932] Hardware name: ProLiant DL360 G4
> [ 0.983916] sysfs: attrs not set by subsystem for group: cpu/
> [ 0.987030] Modules linked in:
> [ 0.988664] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #6
> [ 0.991639] Call Trace:
> [ 0.992911] [<ffffffff8104d11a>] warn_slowpath_common+0x7a/0xb0
> [ 0.995903] [<ffffffff8104d1f1>] warn_slowpath_fmt+0x41/0x50
> [ 0.998593] [<ffffffff8115277c>] internal_create_group+0x18c/0x1f0
> [ 1.001366] [<ffffffff8115280e>] sysfs_create_group+0xe/0x10
> [ 1.003898] [<ffffffff81376cf6>] device_add_groups+0x46/0x80
> [ 1.006955] [<ffffffff81377d8d>] device_add+0x46d/0x6a0
> [ 1.009565] [<ffffffff813778e1>] ? device_private_init+0x51/0x90
> [ 1.012806] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 1.015866] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
> [ 1.018234] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 1.021408] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
> [ 1.025517] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
> [ 1.029102] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
> [ 1.031844] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
> [ 1.034571] [<ffffffff815f3794>] kernel_thread_helper+0x4/0x10
> [ 1.037734] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
> [ 1.040790] [<ffffffff815f3790>] ? gs_change+0xb/0xb
> [ 1.043354] ---[ end trace 319c95c486d7d9cd ]---
> [ 1.045536] ------------[ cut here ]------------
> [ 1.047640] WARNING: at /data/kernel/linux-2.6-git/kernel/events/core.c:7144 perf_event_sysfs_init+0x70/0x9a()
> [ 1.052595] Hardware name: ProLiant DL360 G4
> [ 1.055027] Failed to register pmu: cpu, reason -22
> [ 1.057720] Modules linked in:
> [ 1.059284] Pid: 1, comm: swapper/0 Tainted: G W 3.4.0-rc1-x86_64 #6
> [ 1.062785] Call Trace:
> [ 1.064094] [<ffffffff8104d11a>] warn_slowpath_common+0x7a/0xb0
> [ 1.067192] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 1.070305] [<ffffffff8104d1f1>] warn_slowpath_fmt+0x41/0x50
> [ 1.073129] [<ffffffff810a7244>] ? pmu_dev_alloc+0xb4/0xe0
> [ 1.075771] [<ffffffff81a989e5>] perf_event_sysfs_init+0x70/0x9a
> [ 1.078878] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
> [ 1.081879] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
> [ 1.084714] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
> [ 1.087754] [<ffffffff815f3794>] kernel_thread_helper+0x4/0x10
> [ 1.090639] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
> [ 1.093372] [<ffffffff815f3790>] ? gs_change+0xb/0xb
> [ 1.096312] ---[ end trace 319c95c486d7d9ce ]---
That looks reasonable to me.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> fs/sysfs/group.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index dd1701c..2df555c 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -67,7 +67,11 @@ static int internal_create_group(struct kobject *kobj, int update,
> /* Updates may happen before the object has been instantiated */
> if (unlikely(update && !kobj->sd))
> return -EINVAL;
> -
> + if (!grp->attrs) {
> + WARN(1, "sysfs: attrs not set by subsystem for group: %s/%s\n",
> + kobj->name, grp->name ? "" : grp->name);
> + return -EINVAL;
> + }
> if (grp->name) {
> error = sysfs_create_subdir(kobj, grp->name, &sd);
> if (error)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v2] Prevent crash on unset sysfs group attributes
2012-04-03 7:41 ` [PATCH v2] Prevent crash on unset sysfs group attributes Bruno Prémont
2012-04-03 7:51 ` Eric W. Biederman
@ 2012-04-03 7:53 ` Ingo Molnar
2012-04-03 7:59 ` [PATCH v2a] sysfs: " Bruno Prémont
2 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 7:53 UTC (permalink / raw)
To: Bruno Prémont
Cc: Eric W. Biederman, Greg KH, Peter Zijlstra, linux-kernel, Linus Torvalds
* Bruno Prémont <bonbons@linux-vserver.org> wrote:
> Do not let the kernel crash when a device is registered with
> sysfs while group attributes are not set (aka NULL).
>
> Warn about the offender with some information about the offending
> device.
>
> This would warn instead of trying NULL pointer deref like:
> BUG: unable to handle kernel NULL pointer dereference at
> (null) IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> PGD 0
> Oops: 0000 [#1] SMP
> CPU 0
> Modules linked in:
>
> Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant
> DL360 G4 RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>]
> internal_create_group+0x83/0x1a0 RSP: 0018:ffff88019485fd70 EFLAGS:
> 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX:
> 0000000000000001 RDX: ffff880192e99908 RSI: ffff880192e99630 RDI:
> ffffffff81a26c60 RBP: ffff88019485fdc0 R08: 0000000000000000 R09:
> 0000000000000000 R10: ffff880192e99908 R11: 0000000000000000 R12:
> ffffffff81a16a00 R13: ffff880192e99908 R14: ffffffff81a16900 R15:
> 0000000000000000 FS: 0000000000000000(0000) GS:ffff88019bc00000(0000)
> knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
> 000000008005003b CR2: 0000000000000000 CR3: 0000000001a0c000 CR4:
> 00000000000007f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400 Process swapper/0 (pid: 1, threadinfo
> ffff88019485e000, task ffff880194878000) Stack:
> ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
> ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
> 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
> Call Trace:
> [<ffffffff811527be>] sysfs_create_group+0xe/0x10
> [<ffffffff81376ca6>] device_add_groups+0x46/0x80
> [<ffffffff81377d3d>] device_add+0x46d/0x6a0
> ...
>
> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
> ---
>
> On Tue, 3 Apr 2012 09:15:43 Ingo Molnar wrote:
> > > > Greg, is this ok for you or should the check be moved out to
> > > > calling internal_create_group()?
> > >
> > > Please put changes in internal_create_group where all of the
> > > rest of the checks are.
> >
> > So you *do* agree that a check in a generic place is useful
> > after all? ;-)
> >
> > > We should do something like:
> > > if (!grp->attrs) {
> > > WARN(1, "sysfs: idiot subsystem did not include attrs for group: %s/%s\n"
> > > kobj->name, grp->name?"":grp->name);
> > > return -EINVAL;
> > > }
> > >
> > > As it stands your patch is horrible it leaves sysfs in an
> > > inconsistent state. Creating the directory and leaving it
> > > there. Not returning an error code. It looks like there are
> > > all kinds of weird problems that removing the group or
> > > updating the group could get into if we go with your patch.
> >
> > This is actually a sensible suggestion. Bruno, mind updating
> > your patch to do something like this? Assuming Greg agrees with
> > putting the check/warning there.
>
> Here come a respin with Eric's suggestion.
>
> In my case it would show the following result:
>
> [ 0.975025] ------------[ cut here ]------------
> [ 0.977507] WARNING: at /data/kernel/linux-2.6-git/fs/sysfs/group.c:72 internal_create_group+0x18c/0x1f0()
> [ 0.981932] Hardware name: ProLiant DL360 G4
> [ 0.983916] sysfs: attrs not set by subsystem for group: cpu/
> [ 0.987030] Modules linked in:
> [ 0.988664] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #6
> [ 0.991639] Call Trace:
> [ 0.992911] [<ffffffff8104d11a>] warn_slowpath_common+0x7a/0xb0
> [ 0.995903] [<ffffffff8104d1f1>] warn_slowpath_fmt+0x41/0x50
> [ 0.998593] [<ffffffff8115277c>] internal_create_group+0x18c/0x1f0
> [ 1.001366] [<ffffffff8115280e>] sysfs_create_group+0xe/0x10
> [ 1.003898] [<ffffffff81376cf6>] device_add_groups+0x46/0x80
> [ 1.006955] [<ffffffff81377d8d>] device_add+0x46d/0x6a0
> [ 1.009565] [<ffffffff813778e1>] ? device_private_init+0x51/0x90
> [ 1.012806] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 1.015866] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
> [ 1.018234] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 1.021408] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
> [ 1.025517] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
> [ 1.029102] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
> [ 1.031844] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
> [ 1.034571] [<ffffffff815f3794>] kernel_thread_helper+0x4/0x10
> [ 1.037734] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
> [ 1.040790] [<ffffffff815f3790>] ? gs_change+0xb/0xb
> [ 1.043354] ---[ end trace 319c95c486d7d9cd ]---
> [ 1.045536] ------------[ cut here ]------------
> [ 1.047640] WARNING: at /data/kernel/linux-2.6-git/kernel/events/core.c:7144 perf_event_sysfs_init+0x70/0x9a()
> [ 1.052595] Hardware name: ProLiant DL360 G4
> [ 1.055027] Failed to register pmu: cpu, reason -22
> [ 1.057720] Modules linked in:
> [ 1.059284] Pid: 1, comm: swapper/0 Tainted: G W 3.4.0-rc1-x86_64 #6
> [ 1.062785] Call Trace:
> [ 1.064094] [<ffffffff8104d11a>] warn_slowpath_common+0x7a/0xb0
> [ 1.067192] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> [ 1.070305] [<ffffffff8104d1f1>] warn_slowpath_fmt+0x41/0x50
> [ 1.073129] [<ffffffff810a7244>] ? pmu_dev_alloc+0xb4/0xe0
> [ 1.075771] [<ffffffff81a989e5>] perf_event_sysfs_init+0x70/0x9a
> [ 1.078878] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
> [ 1.081879] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
> [ 1.084714] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
> [ 1.087754] [<ffffffff815f3794>] kernel_thread_helper+0x4/0x10
> [ 1.090639] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
> [ 1.093372] [<ffffffff815f3790>] ? gs_change+0xb/0xb
> [ 1.096312] ---[ end trace 319c95c486d7d9ce ]---
>
>
>
> fs/sysfs/group.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index dd1701c..2df555c 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -67,7 +67,11 @@ static int internal_create_group(struct kobject *kobj, int update,
> /* Updates may happen before the object has been instantiated */
> if (unlikely(update && !kobj->sd))
> return -EINVAL;
> -
> + if (!grp->attrs) {
> + WARN(1, "sysfs: attrs not set by subsystem for group: %s/%s\n",
> + kobj->name, grp->name ? "" : grp->name);
> + return -EINVAL;
> + }
Acked-by: Ingo Molnar <mingo@elte.hu>
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2a] sysfs: Prevent crash on unset sysfs group attributes
2012-04-03 7:41 ` [PATCH v2] Prevent crash on unset sysfs group attributes Bruno Prémont
2012-04-03 7:51 ` Eric W. Biederman
2012-04-03 7:53 ` Ingo Molnar
@ 2012-04-03 7:59 ` Bruno Prémont
2012-04-03 8:06 ` Ingo Molnar
2 siblings, 1 reply; 28+ messages in thread
From: Bruno Prémont @ 2012-04-03 7:59 UTC (permalink / raw)
To: Greg KH
Cc: Ingo Molnar, Eric W. Biederman, Peter Zijlstra, linux-kernel,
Linus Torvalds
Do not let the kernel crash when a device is registered with
sysfs while group attributes are not set (aka NULL).
Warn about the offender with some information about the offending
device.
This would warn instead of trying NULL pointer deref like:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
PGD 0
Oops: 0000 [#1] SMP
CPU 0
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
Stack:
ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
Call Trace:
[<ffffffff811527be>] sysfs_create_group+0xe/0x10
[<ffffffff81376ca6>] device_add_groups+0x46/0x80
[<ffffffff81377d3d>] device_add+0x46d/0x6a0
...
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
---
Resending with fixed commit description message formatting!
Stupid MUA thinks it knows how to wrap lines and that it must reformat
whole mail on paste...
fs/sysfs/group.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index dd1701c..2df555c 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -67,7 +67,11 @@ static int internal_create_group(struct kobject *kobj, int update,
/* Updates may happen before the object has been instantiated */
if (unlikely(update && !kobj->sd))
return -EINVAL;
-
+ if (!grp->attrs) {
+ WARN(1, "sysfs: attrs not set by subsystem for group: %s/%s\n",
+ kobj->name, grp->name ? "" : grp->name);
+ return -EINVAL;
+ }
if (grp->name) {
error = sysfs_create_subdir(kobj, grp->name, &sd);
if (error)
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 7:50 ` [PATCH] Prevent crash on missing sysfs attribute group Eric W. Biederman
@ 2012-04-03 8:04 ` Ingo Molnar
2012-04-03 8:52 ` Eric W. Biederman
2012-04-03 14:27 ` Peter Zijlstra
1 sibling, 1 reply; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 8:04 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Bruno Prémont, Greg KH, Peter Zijlstra, linux-kernel,
Linus Torvalds
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Huh, so put repeated, duplicated, inconsistently applied sanity
> > checks into dozens of sysfs attribute using kernel subsystems?
>
> [...]
>
> No. I was not talking about every usage site.
Note, I'm not arguing that this isn't a bug in the P4 PMU driver
- it is clearly a bug and I've applied the fix for it. I'm
arguing about the escallation vector that this bug takes - that
is unnecessarily disruptive:
You were talking about:
> >> FIX perf to include sanity checks.
and what the PMU drivers do here is not uncommon at all, and the
bug (for which I applied the fix and will push to Linus ASAP) is
not uncommon either:
Bugs happen and indirections happen too. perf uses a generic PMU
driver layer where the lower level layers register themselves.
There's at least a dozen similar constructs in the kernel and
you suggest that the right solution is to put checks in every
one of them, while the nice patch from Bruno could catch it too,
in one central place?
If the PMU code used those attributes directly and could
crash/misbehave then you'd have a point. But the first thing
that makes real use of these objects is sysfs - so it's
trivially useful to at minimum have a sanity check there...
> [...] I was talking about the sites that are don't have a
> direct call chain to the sysfs methods and instead do
> something clever that makes backtraces worthless.
>
> In the normal case sysfs registration problems are simple to
> trace back to their source because the backtrace points a
> finger at the piece of code that when registering had a
> problem.
You mean the crash backtrace?
I don't think we should spuriously crash the kernel on NULL
pointer input to generic facilities, especially when a check is
so simple and would catch so many similar patterns of bugs.
That lack of a check escallated a simple missing (and
unimportant) attribute into a "box won't boot at all" bug.
*That* is not acceptable behavior and robustness from a generic
facility, in my book.
In that sense the crash behaves like a BUG_ON().
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v2a] sysfs: Prevent crash on unset sysfs group attributes
2012-04-03 7:59 ` [PATCH v2a] sysfs: " Bruno Prémont
@ 2012-04-03 8:06 ` Ingo Molnar
0 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 8:06 UTC (permalink / raw)
To: Bruno Prémont
Cc: Greg KH, Eric W. Biederman, Peter Zijlstra, linux-kernel, Linus Torvalds
* Bruno Prémont <bonbons@linux-vserver.org> wrote:
> Do not let the kernel crash when a device is registered with
> sysfs while group attributes are not set (aka NULL).
>
> Warn about the offender with some information about the offending
> device.
>
> This would warn instead of trying NULL pointer deref like:
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> PGD 0
> Oops: 0000 [#1] SMP
> CPU 0
> Modules linked in:
>
> Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
> RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
> RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
> R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
> Stack:
> ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
> ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
> 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
> Call Trace:
> [<ffffffff811527be>] sysfs_create_group+0xe/0x10
> [<ffffffff81376ca6>] device_add_groups+0x46/0x80
> [<ffffffff81377d3d>] device_add+0x46d/0x6a0
> ...
>
> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Still-Acked-by: Ingo Molnar <mingo@elte.hu>
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?
2012-04-02 20:04 ` David Ahern
@ 2012-04-03 8:30 ` Jiri Olsa
0 siblings, 0 replies; 28+ messages in thread
From: Jiri Olsa @ 2012-04-03 8:30 UTC (permalink / raw)
To: David Ahern
Cc: Bruno Prémont, Eric W. Biederman, linux-kernel, Greg KH,
Linus Torvalds, Ingo Molnar, Peter Zijlstra
On Mon, Apr 02, 2012 at 02:04:47PM -0600, David Ahern wrote:
> On 4/2/12 1:34 PM, Bruno Prémont wrote:
> >[adding a few perf people to CC as might originate from perf]
> >
> >On Mon, 02 April 2012 Eric W. Biederman wrote:
> >>Bruno Prémont writes:
> >>>On Mon, 2 Apr 2012 16:27:16 Bruno Prémont wrote:
> >>>>Trying to boot a freshly built 3.4-rc1 (x86_64) kernel I'm getting the following
> >>>>trace (server is HP Proliant G4):
> >>>>
> >>>>[ 0.986317] BUG: unable to handle kernel NULL pointer dereference at (null)
> >>>>[ 0.990542] IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> >>>>[ 0.993693] PGD 0
> >>>>[ 0.994682] Oops: 0000 [#1] SMP
> >>>>[ 0.996198] CPU 0
> >>>>[ 0.996198] Modules linked in:
> >>>>[ 0.996198]
> >>>>[ 0.996198] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
> >>>>[ 0.996198] RIP: 0010:[<ffffffff81152673>] [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> >>>>[ 0.996198] RSP: 0018:ffff88019485fd70 EFLAGS: 00010202
> >>>>[ 0.996198] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
> >>>>[ 0.996198] RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
> >>>>[ 0.996198] RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
> >>>>[ 0.996198] R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
> >>>>[ 0.996198] R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
> >>>>[ 0.996198] FS: 0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
> >>>>[ 0.996198] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >>>>[ 0.996198] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
> >>>>[ 0.996198] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >>>>[ 0.996198] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >>>>[ 0.996198] Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
> >>>>[ 0.996198] Stack:
> >>>>[ 0.996198] ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
> >>>>[ 0.996198] ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
> >>>>[ 0.996198] 0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
> >>>>[ 0.996198] Call Trace:
> >>>>[ 0.996198] [<ffffffff811527be>] sysfs_create_group+0xe/0x10
> >>>>[ 0.996198] [<ffffffff81376ca6>] device_add_groups+0x46/0x80
> >>>>[ 0.996198] [<ffffffff81377d3d>] device_add+0x46d/0x6a0
> >>>>[ 0.996198] [<ffffffff81377891>] ? device_private_init+0x51/0x90
> >>>>[ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> >>>>[ 0.996198] [<ffffffff810a7228>] pmu_dev_alloc+0x98/0xe0
> >>>>[ 0.996198] [<ffffffff81a98975>] ? utsname_sysctl_init+0x14/0x14
> >>>>[ 0.996198] [<ffffffff81a989c0>] perf_event_sysfs_init+0x4b/0x9a
> >>>>[ 0.996198] [<ffffffff810002ad>] do_one_initcall+0x3d/0x170
> >>>>[ 0.996198] [<ffffffff81a85cbd>] kernel_init+0x12d/0x1be
> >>>>[ 0.996198] [<ffffffff81a85505>] ? rdinit_setup+0x28/0x28
> >>>>[ 0.996198] [<ffffffff815f3714>] kernel_thread_helper+0x4/0x10
> >>>>[ 0.996198] [<ffffffff81a85b90>] ? start_kernel+0x373/0x373
> >>>>[ 0.996198] [<ffffffff815f3710>] ? gs_change+0xb/0xb
> >>>>[ 0.996198] Code: ff 85 c0 0f 85 bc 00 00 00 4c 8b 6d c8 4d 85 ed 74 15 41 8b 45 00 85 c0 0f 84 0b 01 00 00 f0 41 ff 45 00 4c 8b 6d c8 49 8b 5e 10<48> 8b 03 48 85 c0 74 71 45 31 e4 eb 44 49 8b 46 08 48 85 c0 74
> >>>>[ 0.996198] RIP [<ffffffff81152673>] internal_create_group+0x83/0x1a0
> >>>>[ 0.996198] RSP<ffff88019485fd70>
> >>>>[ 0.996198] CR2: 0000000000000000
> >>>>[ 1.131357] ---[ end trace 319c95c486d7d9cd ]---
> >>>>[ 1.133676] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> >>>>[ 1.133677]
> >>>
> >>>The patch below works around it and leaves exactly one trace for WARN_ON() matching
> >>>above BUG.
> >>>With it, system boots to userspace.
> >>>
> >>>Thanks,
> >>>Bruno
> >>>
> >>>---
> >>>diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> >>>index dd1701c..0040ff2 100644
> >>>--- a/fs/sysfs/group.c
> >>>+++ b/fs/sysfs/group.c
> >>>@@ -32,7 +32,8 @@ static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
> >>> struct attribute *const* attr;
> >>> int error = 0, i;
> >>>
> >>>- for (i = 0, attr = grp->attrs; *attr&& !error; i++, attr++) {
> >>>+ WARN_ON(!grp->attrs);
> >>>+ for (i = 0, attr = grp->attrs; attr&& *attr&& !error; i++, attr++) {
> >>> umode_t mode = 0;
> >>>
> >>> /* in update mode, we're changing the permissions or
> >>
> >>Sysfs has not changed in this area from 3.3.
> >>
> >>The sysctl in your backtrace looks like left over addresses on the stack.
> >>
> >>The backtrack indicates this is something perf related going wonky.
> >>
> >>I would suggest you try disabling your perf related options one by one
> >>until the broken one shows up. Or possibly just initially disable perf.
> >
> >Well, I didn't enable perf, all perf-related options that are enabled
> >are selected by X86!
> >
> >Symbol: HAVE_PERF_EVENTS [=y]
> > Type : boolean
> > Selected by: X86 [=y]
> >
> >Symbol: PERF_EVENTS [=y]
> > Type : boolean
> > Prompt: Kernel performance events and counters
> > Defined at init/Kconfig:1157
> > Depends on: HAVE_PERF_EVENTS [=y]
> > Location:
> > -> General setup
> > -> Kernel Performance Events And Counters
> > Selects: ANON_INODES [=y]&& IRQ_WORK [=y]
> > Selected by: X86 [=y] || KVM [=n]&& VIRTUALIZATION [=n]&& HAVE_KVM [=y]&& PCI [=y]&& NET [=y]
> >
> >Symbol: HAVE_PERF_EVENTS_NMI [=y]
> > Type : boolean
> > Selected by: X86 [=y]
> >
> >>This looks like one of those crazy things where something registers
> >>with the perf subsystem, and then perf later registers it with sysfs,
> >>and whatever was registered did not have set the needed group attrs.
> >
> >
> > From quick-reading kernel/events/core.c which contains perf_event_sysfs_init()
> >and pmu_dev_alloc() and commits from v3.3..v3.4 for that file
> >commit 0c9d42ed4cee2aa1dfc3a260b741baae8615744f (perf, x86: Provide means
> >for disabling userspace RDPMC) by Peter looks like a possible
> >candidate or at least startpoint:
> >
> >diff --git a/kernel/events/core.c b/kernel/events/core.c
> >index 05affc3..dcd4049 100644
> >--- a/kernel/events/core.c
> >+++ b/kernel/events/core.c
> >@@ -5505,6 +5505,7 @@ static int pmu_dev_alloc(struct pmu *pmu)
> > if (!pmu->dev)
> > goto out;
> >
> >+ pmu->dev->groups = pmu->attr_groups;
> > device_initialize(pmu->dev);
> > ret = dev_set_name(pmu->dev, "%s", pmu->name);
> > if (ret)
> >
> >Will try bisecting corresponding merge tomorrow when I have full access to affected
> >system.
>
> Perhaps:
> 641cc93 perf: Adding sysfs group format attribute for pmu device
>
> David
hi,
looks like this is related to a bug just fixed by Peter:
Commit-ID: 7b8e6da46b921d30ac1553cac56d8fb74f0b431d
Gitweb:
http://git.kernel.org/tip/7b8e6da46b921d30ac1553cac56d8fb74f0b431d
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
AuthorDate: Tue, 27 Mar 2012 16:50:42 +0200
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 3 Apr 2012 08:33:38 +0200
perf/x86/p4: Add format attributes
jirka
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 8:04 ` Ingo Molnar
@ 2012-04-03 8:52 ` Eric W. Biederman
2012-04-03 10:16 ` Ingo Molnar
0 siblings, 1 reply; 28+ messages in thread
From: Eric W. Biederman @ 2012-04-03 8:52 UTC (permalink / raw)
To: Ingo Molnar
Cc: Bruno Prémont, Greg KH, Peter Zijlstra, linux-kernel,
Linus Torvalds
Ingo Molnar <mingo@kernel.org> writes:
> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> > Huh, so put repeated, duplicated, inconsistently applied sanity
>> > checks into dozens of sysfs attribute using kernel subsystems?
>>
>> [...]
>>
>> No. I was not talking about every usage site.
>
> Note, I'm not arguing that this isn't a bug in the P4 PMU driver
> - it is clearly a bug and I've applied the fix for it. I'm
> arguing about the escallation vector that this bug takes - that
> is unnecessarily disruptive:
>
> You were talking about:
>
>> >> FIX perf to include sanity checks.
>
> and what the PMU drivers do here is not uncommon at all, and the
> bug (for which I applied the fix and will push to Linus ASAP) is
> not uncommon either:
> Bugs happen and indirections happen too. perf uses a generic PMU
> driver layer where the lower level layers register themselves.
> There's at least a dozen similar constructs in the kernel and
> you suggest that the right solution is to put checks in every
> one of them, while the nice patch from Bruno could catch it too,
> in one central place?
What is uncommon is that perf_pmu_register is called from
an early initcall, and then later a device_init call
is used to register the pmu subsystem with sysfs.
That extra delay step is weird. That registering extra early
is weird.
How we get from x86_pmu to the variable simply named pmu
that is registered I am still in the dark about. There is a lot
of weird magic going on in that registration path before
these things get to sysfs.
And those extra steps are what make Bruno's patch largely
useless for this case.
> If the PMU code used those attributes directly and could
> crash/misbehave then you'd have a point. But the first thing
> that makes real use of these objects is sysfs - so it's
> trivially useful to at minimum have a sanity check there...
If the pmu subsystem is doing odd and peculiar things it should strive
to not impose debugging burden on others.
>> [...] I was talking about the sites that are don't have a
>> direct call chain to the sysfs methods and instead do
>> something clever that makes backtraces worthless.
>>
>> In the normal case sysfs registration problems are simple to
>> trace back to their source because the backtrace points a
>> finger at the piece of code that when registering had a
>> problem.
>
> You mean the crash backtrace?
I mean a backtrace when people try and abuse sysfs by accident.
Typically they are backtraces from WARN_ON that I look at. It is common
enough and I look a reasonable number of them. Usually they point back
to the subsystem and the borked piece of code. In this case the
backtrace barely hit the broad side of the barn.
It really irritates me that a stack backtrace is useless for figuring
out that this was something in under arch/x86 let alone for figuring
out that this was p4 related.
So since the perf pmu event subsystem is extremely atypical I am asking
that it be looked at to see if it's structure or sanity checks can
be improved so it is more debuggable when people make stupid mistakes.
Eric
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 8:52 ` Eric W. Biederman
@ 2012-04-03 10:16 ` Ingo Molnar
2012-04-03 10:46 ` Eric W. Biederman
0 siblings, 1 reply; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 10:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Bruno Prémont, Greg KH, Peter Zijlstra, linux-kernel,
Linus Torvalds
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> Ingo Molnar <mingo@kernel.org> writes:
>
> > * Eric W. Biederman <ebiederm@xmission.com> wrote:
> >
> >> > Huh, so put repeated, duplicated, inconsistently applied sanity
> >> > checks into dozens of sysfs attribute using kernel subsystems?
> >>
> >> [...]
> >>
> >> No. I was not talking about every usage site.
> >
> > Note, I'm not arguing that this isn't a bug in the P4 PMU driver
> > - it is clearly a bug and I've applied the fix for it. I'm
> > arguing about the escallation vector that this bug takes - that
> > is unnecessarily disruptive:
> >
> > You were talking about:
> >
> >> >> FIX perf to include sanity checks.
> >
> > and what the PMU drivers do here is not uncommon at all, and the
> > bug (for which I applied the fix and will push to Linus ASAP) is
> > not uncommon either:
>
> > Bugs happen and indirections happen too. perf uses a generic
> > PMU driver layer where the lower level layers register
> > themselves. There's at least a dozen similar constructs in
> > the kernel and you suggest that the right solution is to put
> > checks in every one of them, while the nice patch from Bruno
> > could catch it too, in one central place?
>
> What is uncommon is that perf_pmu_register is called from an
> early initcall, and then later a device_init call is used to
> register the pmu subsystem with sysfs.
This has no relevance to the bug and crash pattern itself
whatsoever, so stop blathering about unrelated things.
Not filling out a sysfs object attribute is an *easy* driver
level mistake, I've seen it happen on numerous occasions. Not
crashing on it in the sysfs layer is an *obvious* debugging
helper, and I don't understand why you are even arguing about
this.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 10:16 ` Ingo Molnar
@ 2012-04-03 10:46 ` Eric W. Biederman
2012-04-03 22:34 ` Ingo Molnar
0 siblings, 1 reply; 28+ messages in thread
From: Eric W. Biederman @ 2012-04-03 10:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: Bruno Prémont, Greg KH, Peter Zijlstra, linux-kernel,
Linus Torvalds
Ingo Molnar <mingo@kernel.org> writes:
> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> Ingo Molnar <mingo@kernel.org> writes:
>>
>> > * Eric W. Biederman <ebiederm@xmission.com> wrote:
>> >
>> >> > Huh, so put repeated, duplicated, inconsistently applied sanity
>> >> > checks into dozens of sysfs attribute using kernel subsystems?
>> >>
>> >> [...]
>> >>
>> >> No. I was not talking about every usage site.
>> >
>> > Note, I'm not arguing that this isn't a bug in the P4 PMU driver
>> > - it is clearly a bug and I've applied the fix for it. I'm
>> > arguing about the escallation vector that this bug takes - that
>> > is unnecessarily disruptive:
>> >
>> > You were talking about:
>> >
>> >> >> FIX perf to include sanity checks.
>> >
>> > and what the PMU drivers do here is not uncommon at all, and the
>> > bug (for which I applied the fix and will push to Linus ASAP) is
>> > not uncommon either:
>>
>> > Bugs happen and indirections happen too. perf uses a generic
>> > PMU driver layer where the lower level layers register
>> > themselves. There's at least a dozen similar constructs in
>> > the kernel and you suggest that the right solution is to put
>> > checks in every one of them, while the nice patch from Bruno
>> > could catch it too, in one central place?
>>
>> What is uncommon is that perf_pmu_register is called from an
>> early initcall, and then later a device_init call is used to
>> register the pmu subsystem with sysfs.
>
> This has no relevance to the bug and crash pattern itself
> whatsoever, so stop blathering about unrelated things.
Crashing or BUG_ON or WARN_ON has no relevance to how hard it is to
debug this. They only have relevance on how hard it is to get
the information from a machine that experience this problem.
The call to perf_pmu_register was not in the stack backtrace,
because the call to perf_pmu_register happened long ago and
we put off registering with sysfs until later.
By the time we got to sysfs there was no information available
that would let us know which client of the perf events subsystem
it possibly could be. Not enough information when we register
with sysfs to blame it on something makes it hard to debug.
> Not filling out a sysfs object attribute is an *easy* driver
> level mistake, I've seen it happen on numerous occasions. Not
> crashing on it in the sysfs layer is an *obvious* debugging
> helper, and I don't understand why you are even arguing about
> this.
I agree that not filling out some field of something that is
expected is an easy driver bug to make. As such I would actually
like something to go on the next time someone makes that mistake.
Because the perf pmu subsystem is atypical and has asynchronous
registration with respect to sysfs. These kinds of problems
are harder to find then they need to be.
The only tools to track this down that were realistically available
were git bisect and asking on the list of developers if this bug
looked familiar. There was really not enough information at the point
of the crash to find which attribute was not properly initialized
without being intimately familiar with the perf pmu subsystem.
Having to resort to a git bisect when a few checks extra checks
could have caught the culprit red handed and we could have had
a the function name where the that started the registration
of the sysfs attribute to start debugging with.
Eric
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 7:50 ` [PATCH] Prevent crash on missing sysfs attribute group Eric W. Biederman
2012-04-03 8:04 ` Ingo Molnar
@ 2012-04-03 14:27 ` Peter Zijlstra
2012-04-03 23:22 ` Eric W. Biederman
1 sibling, 1 reply; 28+ messages in thread
From: Peter Zijlstra @ 2012-04-03 14:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Bruno Prémont, Greg KH, linux-kernel, Linus Torvalds
On Tue, 2012-04-03 at 00:50 -0700, Eric W. Biederman wrote:
>
> So I am asking that since perf is built in a way that actively makes
> debugging these kinds of problems hard that you please add additional
> debugging code to perf_pmu_register or some other better location so
> that simply registering something buggy with perf will show the bug.
>
>
Is there a convenient helper function that we can use that validates the
attribute_group structure? We could use such a function to do the
validation at a point where we still know where it came from.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 10:46 ` Eric W. Biederman
@ 2012-04-03 22:34 ` Ingo Molnar
0 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2012-04-03 22:34 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Bruno Prémont, Greg KH, Peter Zijlstra, linux-kernel,
Linus Torvalds
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> > This has no relevance to the bug and crash pattern itself
> > whatsoever, so stop blathering about unrelated things.
>
> Crashing or BUG_ON or WARN_ON has no relevance to how hard it
> is to debug this. [...]
Erm, so you think the difference between a nice WARN_ON() and a
machine that *DOES NOT BOOT* is irrelevant?
In which universe? Smoking what kind of drugs?
Seriously, you need a reality check. We settled the BUG_ON()
versus WARN_ON() debate about a decade ago, in favor of
WARN_ON().
Thanks,
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 14:27 ` Peter Zijlstra
@ 2012-04-03 23:22 ` Eric W. Biederman
2012-04-03 23:26 ` Greg KH
0 siblings, 1 reply; 28+ messages in thread
From: Eric W. Biederman @ 2012-04-03 23:22 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Bruno Prémont, Greg KH, linux-kernel, Linus Torvalds
Peter Zijlstra <peterz@infradead.org> writes:
> On Tue, 2012-04-03 at 00:50 -0700, Eric W. Biederman wrote:
>>
>> So I am asking that since perf is built in a way that actively makes
>> debugging these kinds of problems hard that you please add additional
>> debugging code to perf_pmu_register or some other better location so
>> that simply registering something buggy with perf will show the bug.
>>
>>
> Is there a convenient helper function that we can use that validates the
> attribute_group structure? We could use such a function to do the
> validation at a point where we still know where it came from.
There isn't but I was just thinking before you sent this that we could
really use one.
Eric
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] Prevent crash on missing sysfs attribute group
2012-04-03 23:22 ` Eric W. Biederman
@ 2012-04-03 23:26 ` Greg KH
0 siblings, 0 replies; 28+ messages in thread
From: Greg KH @ 2012-04-03 23:26 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Peter Zijlstra, Ingo Molnar, Bruno Prémont, linux-kernel,
Linus Torvalds
On Tue, Apr 03, 2012 at 04:22:46PM -0700, Eric W. Biederman wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > On Tue, 2012-04-03 at 00:50 -0700, Eric W. Biederman wrote:
> >>
> >> So I am asking that since perf is built in a way that actively makes
> >> debugging these kinds of problems hard that you please add additional
> >> debugging code to perf_pmu_register or some other better location so
> >> that simply registering something buggy with perf will show the bug.
> >>
> >>
> > Is there a convenient helper function that we can use that validates the
> > attribute_group structure? We could use such a function to do the
> > validation at a point where we still know where it came from.
>
> There isn't but I was just thinking before you sent this that we could
> really use one.
Let me look into this some more, the driver core really should be
protecting you from doing something like this here, sysfs shouldn't be
getting involved (not to say that the patch is incorrect, it isn't, I'll
queue it up, but that something more looks to be needed to keep from
hitting that problem in the first place.)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2012-04-03 23:26 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-02 14:27 [3.4-rc1 crash]: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related? Bruno Prémont
2012-04-02 14:50 ` Bruno Prémont
2012-04-02 19:01 ` Eric W. Biederman
2012-04-02 19:34 ` Bruno Prémont
2012-04-02 20:04 ` David Ahern
2012-04-03 8:30 ` Jiri Olsa
2012-04-02 21:24 ` Peter Zijlstra
2012-04-02 21:46 ` Peter Zijlstra
2012-04-03 5:38 ` Bruno Prémont
2012-04-03 6:02 ` Ingo Molnar
2012-04-03 6:17 ` [PATCH] Prevent crash on missing sysfs attribute group Bruno Prémont
2012-04-03 6:31 ` Ingo Molnar
2012-04-03 7:11 ` Eric W. Biederman
2012-04-03 7:15 ` Ingo Molnar
2012-04-03 7:41 ` [PATCH v2] Prevent crash on unset sysfs group attributes Bruno Prémont
2012-04-03 7:51 ` Eric W. Biederman
2012-04-03 7:53 ` Ingo Molnar
2012-04-03 7:59 ` [PATCH v2a] sysfs: " Bruno Prémont
2012-04-03 8:06 ` Ingo Molnar
2012-04-03 7:50 ` [PATCH] Prevent crash on missing sysfs attribute group Eric W. Biederman
2012-04-03 8:04 ` Ingo Molnar
2012-04-03 8:52 ` Eric W. Biederman
2012-04-03 10:16 ` Ingo Molnar
2012-04-03 10:46 ` Eric W. Biederman
2012-04-03 22:34 ` Ingo Molnar
2012-04-03 14:27 ` Peter Zijlstra
2012-04-03 23:22 ` Eric W. Biederman
2012-04-03 23:26 ` Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.