: NULL pointer deref in fs/sysfs/group.c:create_files -- sysctl related?

3.4-rc1 crash NAK Bruno Prémont 8 participants 28 messages Apr 2, 2012 – Apr 3, 2012

Subsystems (2)

perf events Driver core

lore

Share & tools

lore

Bruno Prémont

author

2012-04-03 07:04 UTC #0 lore raw

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

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

Bruno Prémont

author

2012-04-03 08:03 UTC #1 lore raw

Quoted 42 lines · 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

Quoted 8 lines

[    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

---

fs/sysfs/group.c +2 -1

index dd1701c..0040ff2 100644
@@ -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

Eric W. Biederman

2012-04-02 18:57 UTC #2 lore raw

Quoted 65 lines · Bruno Prémont

Quoted 42 lines · 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

Quoted 8 lines

[    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

---

fs/sysfs/group.c +0 -0

index dd1701c..0040ff2 100644

fs/sysfs/group.c static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj, · line 39

Quoted 9 lines

fs/sysfs/group.c +2 -1

@@ -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

Bruno Prémont

author

2012-04-02 19:34 UTC #3 lore raw

[adding a few perf people to CC as might originate from perf]

Quoted 78 lines · On Mon, 02 April 2012 Eric W. Biederman wrote:

Quoted 65 lines · Bruno Prémont

Quoted 42 lines · 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

Quoted 8 lines

[    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

---

fs/sysfs/group.c +0 -0

index dd1701c..0040ff2 100644

fs/sysfs/group.c static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj, · line 39

Quoted 9 lines

fs/sysfs/group.c +2 -1

@@ -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.

Quoted 6 lines

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]

Quoted 6 lines

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:

kernel/events/core.c +1 -0

index 05affc3..dcd4049 100644
@@ -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

David Ahern

2012-04-02 20:04 UTC #4 lore raw

Quoted 134 lines · Bruno Prémont

[adding a few perf people to CC as might originate from perf]
Quoted 78 lines · On Mon, 02 April 2012 Eric W. Biederman wrote:
Quoted 65 lines · Bruno Prémont
Quoted 42 lines · 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
Quoted 8 lines
[    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
---
fs/sysfs/group.c +0 -0
index dd1701c..0040ff2 100644
fs/sysfs/group.c static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj, · line 39
Quoted 9 lines
fs/sysfs/group.c +2 -1
@@ -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.
Quoted 6 lines
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]
Quoted 3 lines
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:
kernel/events/core.c +1 -0
index 05affc3..dcd4049 100644
@@ -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)

Quoted 2 lines

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

Jiri Olsa

2012-04-03 08:30 UTC #5 lore raw

Quoted 135 lines · David Ahern

Quoted 134 lines · Bruno Prémont
[adding a few perf people to CC as might originate from perf]
Quoted 78 lines · On Mon, 02 April 2012 Eric W. Biederman wrote:
Quoted 65 lines · Bruno Prémont
Quoted 42 lines · 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
Quoted 8 lines
[    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
---
fs/sysfs/group.c +0 -0
index dd1701c..0040ff2 100644
fs/sysfs/group.c static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj, · line 39
Quoted 9 lines
fs/sysfs/group.c +2 -1
@@ -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.
Quoted 6 lines
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]
Quoted 3 lines
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:
kernel/events/core.c +1 -0
index 05affc3..dcd4049 100644
@@ -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)

Quoted 7 lines

Quoted 2 lines
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 <[email protected]>
AuthorDate: Tue, 27 Mar 2012 16:50:42 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 3 Apr 2012 08:33:38 +0200

perf/x86/p4: Add format attributes

jirka

Peter Zijlstra

2012-04-02 21:32 UTC #6 lore raw

In reply to Bruno Prémont

Quoted 1 line · Bruno Prémont

Quoted 1 line

[    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?

Peter Zijlstra

maintainer

2012-04-02 21:46 UTC #7 lore raw

Quoted 4 lines · Peter Zijlstra

Quoted 1 line · Bruno Prémont
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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?

Bruno Prémont

author Tested-by

2012-04-03 05:39 UTC #8 lore raw

Quoted 9 lines · On Mon, 02 Apr 2012 23:46:33 Peter Zijlstra wrote:

Quoted 4 lines · Peter Zijlstra
Quoted 1 line · Bruno Prémont
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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 <[email protected]>

Ingo Molnar

2012-04-03 06:02 UTC #9 lore raw

In reply to Peter Zijlstra

Quoted 9 lines · Peter Zijlstra

Quoted 4 lines · Peter Zijlstra
Quoted 1 line · Bruno Prémont
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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

Bruno Prémont

author

2012-04-03 06:17 UTC #10 lore raw

PATCH 1/1 Prevent crash on missing sysfs attribute group

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 <[email protected]>

---

Quoted 10 lines · On Tue, 3 Apr 2012 08:02:52 +0200 Ingo Molnar wrote:

Quoted 8 lines · Peter Zijlstra
Quoted 4 lines · Peter Zijlstra
Quoted 1 line · Bruno Prémont
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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?

Quoted 7 lines

Quoted 1 line
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()?

---

fs/sysfs/group.c +2 -1

index dd1701c..0040ff2 100644
@@ -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

Ingo Molnar

Acked-by on v1 1/1

2012-04-03 06:31 UTC #11 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 66 lines · Bruno Prémont

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 <[email protected]>
---
Quoted 10 lines · On Tue, 3 Apr 2012 08:02:52 +0200 Ingo Molnar wrote:
Quoted 8 lines · Peter Zijlstra
Quoted 4 lines · Peter Zijlstra
Quoted 1 line · Bruno Prémont
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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?
Quoted 7 lines
Quoted 1 line
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()?
---
fs/sysfs/group.c +0 -0
index dd1701c..0040ff2 100644

fs/sysfs/group.c static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj, · line 37

Quoted 7 lines

fs/sysfs/group.c +2 -1

@@ -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 <[email protected]>

Thanks,

Ingo

Eric W. Biederman

Nacked-by on v1 1/1 NAK

2012-04-03 07:08 UTC #12 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

In reply to Bruno Prémont

Nacked-by "Eric W. Biederman" <[email protected]>

Quoted 3 lines · Bruno Prémont

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.

Quoted 5 lines

Quoted 5 lines
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.

Quoted 2 lines

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

Quoted 15 lines

---

fs/sysfs/group.c +2 -1

index dd1701c..0040ff2 100644
@@ -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

Ingo Molnar

2012-04-03 07:15 UTC #13 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 10 lines · Eric W. Biederman

Nacked-by "Eric W. Biederman" <[email protected]>
Quoted 3 lines · Bruno Prémont
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.

Quoted 7 lines

Quoted 5 lines
Quoted 5 lines
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.

Quoted 10 lines

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.
Quoted 2 lines
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? ;-)

Quoted 7 lines

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;
}

Quoted 5 lines

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

Bruno Prémont

author

2012-04-03 07:41 UTC #14 lore raw

PATCH v2 1/1 Prevent crash on unset sysfs group attributes

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 <[email protected]>

---

Quoted 22 lines · On Tue, 3 Apr 2012 09:15:43 Ingo Molnar wrote:

Quoted 5 lines
Quoted 2 lines
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? ;-)
Quoted 7 lines
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;
}
Quoted 5 lines
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.

Quoted 3 lines

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(-)

fs/sysfs/group.c +5 -1

index dd1701c..2df555c 100644
@@ -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)

Eric W. Biederman

Acked-by on v2 1/1

2012-04-03 07:48 UTC #15 lore raw

Re: [PATCH v2] Prevent crash on unset sysfs group attributes

Quoted 108 lines · Bruno Prémont

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 <[email protected]>

---

Quoted 22 lines · On Tue, 3 Apr 2012 09:15:43 Ingo Molnar wrote:

Quoted 5 lines
Quoted 2 lines
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? ;-)
Quoted 7 lines
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;
}
Quoted 5 lines
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.

Quoted 3 lines

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

Quoted 8 lines

[    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" <[email protected]>

Quoted 20 lines

 fs/sysfs/group.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

fs/sysfs/group.c +5 -1

index dd1701c..2df555c 100644
@@ -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)

Ingo Molnar

Acked-by on v2 1/1

2012-04-03 07:53 UTC #16 lore raw

Re: [PATCH v2] Prevent crash on unset sysfs group attributes

In reply to Bruno Prémont

Quoted 127 lines · Bruno Prémont

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 <[email protected]>

---

Quoted 22 lines · On Tue, 3 Apr 2012 09:15:43 Ingo Molnar wrote:

Quoted 5 lines
Quoted 2 lines
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? ;-)
Quoted 7 lines
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;
}
Quoted 5 lines
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.

Quoted 3 lines

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(-)

fs/sysfs/group.c +0 -0

index dd1701c..2df555c 100644

fs/sysfs/group.c static int internal_create_group(struct kobject *kobj, int update, · line 74

Quoted 9 lines

fs/sysfs/group.c +5 -1

@@ -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 <[email protected]>

Thanks,

Ingo

Bruno Prémont

author

2012-04-03 07:59 UTC #17 lore raw

PATCH 1/1 sysfs: Prevent crash on unset sysfs group attributes

In reply to Bruno Prémont

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 <[email protected]>

---

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(-)

fs/sysfs/group.c +5 -1

index dd1701c..2df555c 100644
@@ -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)

Ingo Molnar

2012-04-03 08:06 UTC #18 lore raw

Re: [PATCH v2a] sysfs: Prevent crash on unset sysfs group attributes

Quoted 38 lines · Bruno Prémont

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
  ...

Quoted 1 line

Signed-off-by Bruno Prémont <[email protected]>

Still-Acked-by Ingo Molnar <[email protected]>

Thanks,

Ingo

Eric W. Biederman

2012-04-03 07:46 UTC #19 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

In reply to Ingo Molnar

Quoted 20 lines · Ingo Molnar

Quoted 10 lines · Eric W. Biederman
Nacked-by "Eric W. Biederman" <[email protected]>
Quoted 3 lines · Bruno Prémont
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.
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
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.

Quoted 8 lines

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

Ingo Molnar

2012-04-03 08:04 UTC #20 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 6 lines · Eric W. Biederman

Quoted 2 lines
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:

Quoted 1 line

Quoted 1 line
Quoted 1 line
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...

Quoted 8 lines

[...] 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

Eric W. Biederman

2012-04-03 08:48 UTC #21 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 22 lines · Ingo Molnar

Quoted 6 lines · Eric W. Biederman
Quoted 2 lines
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:
Quoted 1 line
Quoted 1 line
Quoted 1 line
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:

Quoted 6 lines

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.

Quoted 4 lines

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.

Quoted 10 lines

Quoted 8 lines
[...] 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

Ingo Molnar

2012-04-03 10:16 UTC #22 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 31 lines · Eric W. Biederman

Quoted 22 lines · Ingo Molnar
Quoted 6 lines · Eric W. Biederman
Quoted 2 lines
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:
Quoted 1 line
Quoted 1 line
Quoted 1 line
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:
Quoted 6 lines
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?

Quoted 3 lines

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

Eric W. Biederman

2012-04-03 10:42 UTC #23 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 33 lines · Ingo Molnar

Quoted 31 lines · Eric W. Biederman
Quoted 28 lines · Ingo Molnar
Quoted 6 lines · Eric W. Biederman
Quoted 2 lines
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:
Quoted 1 line
Quoted 1 line
Quoted 1 line
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?

Quoted 6 lines

Quoted 3 lines
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.

Quoted 5 lines

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

Ingo Molnar

2012-04-03 22:34 UTC #24 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 5 lines · Eric W. Biederman

Quoted 2 lines
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

Peter Zijlstra

maintainer

2012-04-03 14:28 UTC #25 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

In reply to Eric W. Biederman

Quoted 7 lines · Eric W. Biederman

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.

Eric W. Biederman

2012-04-03 23:19 UTC #26 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 11 lines · Peter Zijlstra

Quoted 7 lines · Eric W. Biederman
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

Greg KH

maintainer

2012-04-03 23:26 UTC #27 lore raw

Re: [PATCH] Prevent crash on missing sysfs attribute group

Quoted 10 lines · Eric W. Biederman

Quoted 8 lines · Peter Zijlstra
Quoted 7 lines · Eric W. Biederman
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.

Quoted 6 lines

Quoted 3 lines
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