Random panics seen in 2.6.18-rc1

Random panics seen in 2.6.18-rc1

[Chandra Seetharaman]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

Hi,

While testing delay accounting patches in 2.6.18-rc1, we experienced
random panics in slab allocation/free routines.

Since we have not seen these panics in earlier version we went back and
tested the same set of patches in 2.6.17, and they behaved as expected.

We ran the same test _without_ delay accounting in 2.6.18-rc1, and saw
random panics. Which when tried in 2.6.17, the test did not fail. 2.6.17
kernel ran for more than 20 hrs without any issues.

Since the bugs were seen in slab routines, I replaced mm/slab.c in
2.6.18-rc1 with the same file from 2.6.17(with a small change). I did
not see any crashes.

By adding one patch at a time to 2.6.17's mm/slab.c, I found that the
removal patch is the cause of the panic.
--------------
[PATCH] lockdep: annotate SLAB code

author	Ingo Molnar <mingo@elte.hu>
	Mon, 3 Jul 2006 07:25:28 +0000 (00:25 -0700)
committer	Linus Torvalds <torvalds@g5.osdl.org>
	Mon, 3 Jul 2006 22:27:09 +0000 (15:27 -0700)

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=85c2e03098a7fcf60f9c2f250b0af5a72a0330cf;hp=3936af3445427b6fa71e48dea318ce302b2b0900;hb=2b2d5493e10051694ae3a57ea6a153e3cb4d4488;f=mm/slab.c
--------------

To confirm that, i just removed the above patch from 2.6.18-rc1 and the
tests ran successfully for more than 2 hrs. (is still running)

Attached are the config file, panic stack and mkthreads.c file used to reproduce the problem.

Running
"while true;do  ./mkthreads 1000 100; done"

leads the 2.6.18-rc1 kernel to panic in 30-60 minutes. 

regards,

chandra
-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------


[-- Attachment #2: config --]
[-- Type: text/plain, Size: 36218 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rc1
# Wed Jul 12 19:34:30 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION="2618-rc1"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
CONFIG_X86_GENERICARCH=y
# CONFIG_X86_ES7000 is not set
CONFIG_X86_CYCLONE_TIMER=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
# CONFIG_HPET_TIMER is not set
CONFIG_NR_CPUS=128
# CONFIG_SCHED_SMT is not set
# CONFIG_SCHED_MC is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_EFI_VARS is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
# CONFIG_NUMA is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_EFI=y
CONFIG_IRQBALANCE=y
CONFIG_BOOT_IOREMAP=y
CONFIG_REGPARM=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set
CONFIG_SUSPEND_SMP=y

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_HOTKEY is not set
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_DOCK is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
CONFIG_APM_ALLOW_INTS=y
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_CPU_FREQ_STAT is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# CPUFreq processor drivers
#
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
CONFIG_ATM_CLIP_NO_ICMP=y
# CONFIG_ATM_LANE is not set
# CONFIG_ATM_BR2684 is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
# CONFIG_NET_SCH_CLK_JIFFIES is not set
CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y
# CONFIG_NET_SCH_CLK_CPU is not set

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_ATM=y
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_INGRESS is not set

#
# Classification
#
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y
CONFIG_NET_ESTIMATOR=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
CONFIG_WIRELESS_EXT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
# CONFIG_PNPACPI is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=64000
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEFLOPPY=y
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_OPTI621=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_ONLYDISK=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_ATIIXP is not set
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
CONFIG_BLK_DEV_CY82C693=y
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
CONFIG_BLK_DEV_HPT34X=y
CONFIG_HPT34X_AUTODMA=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_SC1200=y
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
CONFIG_IDE_CHIPSETS=y

#
# Note: most of these also require special kernel boot parameters
#
CONFIG_BLK_DEV_4DRIVES=y
CONFIG_BLK_DEV_ALI14XX=y
CONFIG_BLK_DEV_DTC2278=y
CONFIG_BLK_DEV_HT6560B=y
CONFIG_BLK_DEV_QD65XX=y
CONFIG_BLK_DEV_UMC8672=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=y

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_AHCI is not set
# CONFIG_SCSI_SATA_SVW is not set
# CONFIG_SCSI_ATA_PIIX is not set
# CONFIG_SCSI_SATA_MV is not set
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_SATA_QSTOR is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIL24 is not set
# CONFIG_SCSI_SATA_SIS is not set
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
CONFIG_CD_NO_IDESCSI=y
# CONFIG_AZTCD is not set
# CONFIG_GSCD is not set
# CONFIG_MCDX is not set
# CONFIG_OPTCD is not set
# CONFIG_SJCD is not set
# CONFIG_ISP16_CDI is not set
# CONFIG_CDU535 is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
# CONFIG_BLK_DEV_DM is not set

#
# Fusion MPT device support
#
CONFIG_FUSION=y
CONFIG_FUSION_SPI=y
CONFIG_FUSION_FC=y
CONFIG_FUSION_SAS=y
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=y
# CONFIG_FUSION_LAN is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
CONFIG_NET_VENDOR_SMC=y
# CONFIG_WD80x3 is not set
# CONFIG_ULTRA is not set
# CONFIG_SMC9194 is not set
CONFIG_NET_VENDOR_RACAL=y
# CONFIG_NI52 is not set
# CONFIG_NI65 is not set

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
CONFIG_NET_ISA=y
# CONFIG_E2100 is not set
# CONFIG_EWRK3 is not set
# CONFIG_EEXPRESS is not set
CONFIG_EEXPRESS_PRO=y
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_LP486E is not set
# CONFIG_ETH16I is not set
# CONFIG_NE2000 is not set
# CONFIG_ZNET is not set
# CONFIG_SEEQ8005 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
CONFIG_B44=y
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=y
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set

#
# Token Ring devices
#
CONFIG_TR=y
# CONFIG_IBMTR is not set
# CONFIG_IBMOL is not set
# CONFIG_IBMLS is not set
# CONFIG_3C359 is not set
# CONFIG_TMS380TR is not set
# CONFIG_SMCTR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
# CONFIG_NET_WIRELESS_RTNETLINK is not set

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
# CONFIG_HOSTAP is not set
CONFIG_NET_WIRELESS=y

#
# Wan interfaces
#
CONFIG_WAN=y
# CONFIG_HOSTESS_SV11 is not set
# CONFIG_COSA is not set
# CONFIG_DSCC4 is not set
# CONFIG_LANMEDIA is not set
# CONFIG_SEALEVEL_4021 is not set
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set
# CONFIG_SBNI is not set

#
# ATM drivers
#
# CONFIG_ATM_DUMMY is not set
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
# CONFIG_SKFP is not set
CONFIG_HIPPI=y
# CONFIG_ROADRUNNER is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_NET_FC=y
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_UINPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
CONFIG_STALDRV=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=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_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_I8XX_TCO is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=4096
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
CONFIG_VIDEO_V4L2=y

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
# CONFIG_DVB_CORE is not set

#
# Graphics support
#
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
CONFIG_FB_IMSTT=y
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_IMAC is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
# CONFIG_LOGO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
# CONFIG_MINIX_SUBPARTITION is not set
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_SGI_PARTITION is not set
CONFIG_ULTRIX_PARTITION=y
CONFIG_SUN_PARTITION=y
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Instrumentation Support
#
CONFIG_PROFILING=y
# CONFIG_OPROFILE is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
# CONFIG_UNWIND_INFO is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_CAPABILITIES is not set
# CONFIG_SECURITY_SECLVL is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y

[-- Attachment #3: panic --]
[-- Type: text/plain, Size: 5478 bytes --]

linux1:/tmp # Oops: 0000 [#1]
SMP
Modules linked in:
CPU:    7
EIP:    0060:[<c015fde1>]    Not tainted VLI
EFLAGS: 00010086   (2.6.18-rc12618-rc1 #26)
BUG: unable to handle kernel paging request at virtual address 5a5a5a5a
 printing eip:
c03954fa
*pde = 00000000
EIP is at kmem_cache_alloc+0x2f/0x7f
eax: 00000007   ebx: c7326d00   ecx: 61e59000   edx: 00000000
esi: 00000246   edi: 000000d0   ebp: f52b5f24   esp: f52b5f10
ds: 007b   es: 007b   ss: 0068
Process mkthreads (pid: 6987, ti=f52b4000 task=f34ebab0 task.ti=f52b4000)
Stack: 00000000 c0153312 f6795488 f49a0ecc 61e59000 f52b5f40 c0153312 f608af30
       61e59000 f49a0ecc f52b5fa4 00100070 f52b5f80 c0153caf 00000001 00100070
       f2c8b984 00000000 00061e59 00000000 00000000 00000001 00100073 f6795488
Call Trace:
 [<c0104bc3>] show_stack_log_lvl+0xc3/0xcb
 [<c0104dae>] show_registers+0x197/0x20d
 [<c0104fc9>] die+0x125/0x229
 [<c0117df2>] do_page_fault+0x334/0x5cc
 [<c0104851>] error_code+0x39/0x40
 [<c0153312>] split_vma+0x40/0xce
 [<c0153caf>] mprotect_fixup+0xb0/0x1c0
 [<c0153f39>] sys_mprotect+0x17a/0x211
 [<c0103d1d>] sysenter_past_esp+0x56/0x79
Code: 89 d7 56 53 89 c3 83 ec 08 8b 45 04 89 45 f0 89 d8 e8 a9 f2 ff ff 9c 5e fa e8 ad ec ff ff 89 e0 25 00 e0 ff ff 8b 40 10 8b 14 83 <8b> 02 85 c0 74 36 f0 ff 83 74 02 00 00 8b 02 c7 42 0c 01 00 00
EIP: [<c015fde1>] kmem_cache_alloc+0x2f/0x7f SS:ESP 0068:f52b5f10
 <0>Oops: 0002 [#2]
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000010
 printing eip:
c011931e
*pde = 35098001
SMP
Modules linked in:
CPU:    0
EIP:    0060:[<c03954fa>]    Not tainted VLI
EFLAGS: 00010082   (2.6.18-rc12618-rc1 #26)
EIP is at _spin_lock_irqsave+0x8/0x2a
eax: 00000282   ebx: 5a5a5a5a   ecx: 00000000   edx: 5a5a5a5a
esi: c7213820   edi: c0130dd2   ebp: c04c5ef0   esp: c04c5ef0
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, ti=c04c4000 task=c0418460 task.ti=c04c4000)
Stack: c04c5f08 c0130d32 c013712b f7ca3e54 c04c4000 c0130dd2 c04c5f18 c0130e05
       00000100 c053b880 c04c5f48 c012ac73 000036fc 00000000 c7212be0 00000000
       c04c5f30 c04c5f30 00000052 00000001 c04b8b08 c0508f00 c04c5f64 c01260b4
Call Trace:
 [<c0104bc3>] show_stack_log_lvl+0xc3/0xcb
 [<c0104dae>] show_registers+0x197/0x20d
 [<c0104fc9>] die+0x125/0x229
 [<c0117df2>] do_page_fault+0x334/0x5cc
 [<c0104851>] error_code+0x39/0x40
 [<c0130d32>] __queue_work+0x12/0x59
 [<c0130e05>] delayed_work_timer_fn+0x33/0x37
 [<c012ac73>] run_timer_softirq+0xbd/0x189
 [<c01260b4>] __do_softirq+0x78/0xea
 [<c012615d>] do_softirq+0x37/0x3c
 [<c012619b>] irq_exit+0x39/0x3f
 [<c01131a8>] smp_apic_timer_interrupt+0x64/0x67
 [<c010479f>] apic_timer_interrupt+0x1f/0x24
 [<c0101f81>] cpu_idle+0x9a/0xe1
 [<c01002c5>] rest_init+0x25/0x27
 [<c04ca8ea>] start_kernel+0x1bc/0x21b
 [<c0100210>] 0xc0100210
Code: 01 00 00 00 75 09 f0 81 02 00 00 00 01 31 c9 89 c8 5d c3 55 89 e5 f0 83 28 01 79 05 e8 2c e4 ff ff 5d c3 55 89 c2 89 e5 9c 58 fa <f0> fe 0a 79 1b a9 00 02 00 00 74 0b fb f3 90 80 3a 00 7e f9 fa
EIP: [<c03954fa>] _spin_lock_irqsave+0x8/0x2a SS:ESP 0068:c04c5ef0
 <0>Oops: 0000 [#3]
Kernel panic - not syncing: Fatal exception in interrupt
 BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
 [<c0104afe>] show_trace+0x12/0x14
 [<c0104c15>] dump_stack+0x19/0x1b
 [<c01114fc>] smp_call_function+0xd7/0xdc
 [<c0111555>] smp_send_stop+0x1e/0x27
 [<c0120b40>] panic+0x49/0xe5
 [<c010506e>] die+0x1ca/0x229
 [<c0117df2>] do_page_fault+0x334/0x5cc
 [<c0104851>] error_code+0x39/0x40
 [<c0130d32>] __queue_work+0x12/0x59
 [<c0130e05>] delayed_work_timer_fn+0x33/0x37
 [<c012ac73>] run_timer_softirq+0xbd/0x189
 [<c01260b4>] __do_softirq+0x78/0xea
 [<c012615d>] do_softirq+0x37/0x3c
 [<c012619b>] irq_exit+0x39/0x3f
 [<c01131a8>] smp_apic_timer_interrupt+0x64/0x67
 [<c010479f>] apic_timer_interrupt+0x1f/0x24
 [<c0101f81>] cpu_idle+0x9a/0xe1
 [<c01002c5>] rest_init+0x25/0x27
 [<c04ca8ea>] start_kernel+0x1bc/0x21b
 [<c0100210>] 0xc0100210
SMP
Modules linked in:
CPU:    7
EIP:    0060:[<c011931e>]    Not tainted VLI
EFLAGS: 00010086   (2.6.18-rc12618-rc1 #26)
EIP is at task_rq_lock+0x20/0x5a
eax: 00000000   ebx: c05084e0   ecx: 00000000   edx: f52b5d18
esi: c05084e0   edi: c73dd030   ebp: f52b5cc4   esp: f52b5cb4
ds: 007b   es: 007b   ss: 0068
Process mkthreads (pid: 6987, ti=f52b4000 task=f34ebab0 task.ti=f52b4000)
Stack: f52b5d18 c73dd030 f2e75f74 c724b68c f52b5d28 c0119b0b 00000001 00000080
       00000000 00000000 00000400 00000140 000001c0 00000080 f48e5f74 f517ff74
       c724b694 f4788000 00000007 00000000 f2b01f74 c724b68c 00000000 00000000
Call Trace:
 [<c0104bc3>] show_stack_log_lvl+0xc3/0xcb
 [<c0104dae>] show_registers+0x197/0x20d
 [<c0104fc9>] die+0x125/0x229
 [<c0117df2>] do_page_fault+0x334/0x5cc
 [<c0104851>] error_code+0x39/0x40
 [<c0119b0b>] try_to_wake_up+0x27/0x2db
 [<c0119dce>] wake_up_process+0xf/0x11
 [<c01371e4>] hrtimer_wakeup+0x18/0x1c
 [<c0137160>] hrtimer_run_queues+0x81/0xed
 [<c012abdd>] run_timer_softirq+0x27/0x189
 [<c01260b4>] __do_softirq+0x78/0xea
 [<c012615d>] do_softirq+0x37/0x3c
 [<c012619b>] irq_exit+0x39/0x3f
 [<c01131a8>] smp_apic_timer_interrupt+0x64/0x67
 [<c010479f>] apic_timer_interrupt+0x1f/0x24
 [<c0123803>] do_exit+0xec/0x46f
 [<c01050cd>] do_trap+0x0/0xa3
 [<c0117df2>] do_page_fault+0x334/0x5cc
 [<c0104851>] error_code+0x39/0x40
 [<c0153312>] split_vma+0x40/0xce
 [<c0153caf>] mprotect_fixup+0xb0/0x1c0
 [<c0153f39>] sys_mprotect+0x17a/0x211
 [<c0103d1d>] sysenter_past_esp+0x56/0x79


[-- Attachment #4: mkthreads.c --]
[-- Type: text/x-csrc, Size: 1338 bytes --]

/* gcc -o mkthreads mkthreads.c -lpthread -lm */

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <pthread.h>

int n;
int barrier=1;

#if 0
void *thread_fn(void *arg)
{
	int i = (int) arg;
	int j = 0;
	int k;

	printf("%d starting\n", i);


	for (k=0; k<100000000 ; k++) {
		usleep(1);
		for (j=0;j<1000000000;j++)
			i += j+j-2*j;
	}
	printf("%d ending %d\n", j);	
}
#endif

void *slow_exit(void *arg)
{
	int i = (int) arg;
//	printf("%d starting\n", i);
	usleep((n-i)*2);
//	while (barrier)
//		usleep(500);
//	printf("%d ending\n", i);	
}

int main(int argc, char *argv[])
{
	int i,rc, rep;
	pthread_t *ppthread;
	
	n = 5 ;
	if (argc > 1)
		n = atoi(argv[1]);

	rep = 10;
	if (argc > 2)
		rep = atoi(argv[2]);

	ppthread = malloc(n * sizeof(pthread_t));
	if (ppthread == NULL) {
		printf("Memory allocation failure\n");
		exit(-1);
	}

	while (rep) {
//		printf("%d Create threads\n", rep);
		for (i=0; i<n; i++) {
			rc = pthread_create(&ppthread[i], NULL, 
					    slow_exit, (void *)i);
			if (rc) {
				printf("Error creating thread %d\n", i);
				exit(-1);
			}
		}
//		printf("%d Join threads\n", rep);
		for (i=0; i<n; i++) {
			rc = pthread_join(ppthread[i], NULL);
			if (rc) {
				printf("Error joining thread %d\n", i);
				exit(-1);
			}
		}
		rep--;
	}
//	printf("Done.\n");
}

Re: Random panics seen in 2.6.18-rc1

[Ingo Molnar]

* Chandra Seetharaman <sekharan@us.ibm.com> wrote:

> By adding one patch at a time to 2.6.17's mm/slab.c, I found that the
> following patch is the cause of the panic.
> --------------
> [PATCH] lockdep: annotate SLAB code

great debugging!

I have reviewed that patch, and there's only one chunk that could 
possibly have a functional effect. The patch below undoes it - does that 
fix the crashes you are seeing? [If you have lockdep enabled then this 
patch will cause a lockdep false positive - ignore that one for now, it 
shouldnt impact the crash scenario itself.]

	Ingo

--------------------->
Subject: revert slab.c locking change
From: Ingo Molnar <mingo@elte.hu>

Chandra Seetharaman reported SLAB crashes caused by the slab.c
lock annotation patch. There is only one chunk of that patch
that has a material effect on the slab logic - this patch
undoes that chunk.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 mm/slab.c |    9 ---------
 1 file changed, 9 deletions(-)

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -3100,16 +3100,7 @@ static void free_block(struct kmem_cache
 		if (slabp->inuse == 0) {
 			if (l3->free_objects > l3->free_limit) {
 				l3->free_objects -= cachep->num;
-				/*
-				 * It is safe to drop the lock. The slab is
-				 * no longer linked to the cache. cachep
-				 * cannot disappear - we are using it and
-				 * all destruction of caches must be
-				 * serialized properly by the user.
-				 */
-				spin_unlock(&l3->list_lock);
 				slab_destroy(cachep, slabp);
-				spin_lock(&l3->list_lock);
 			} else {
 				list_add(&slabp->list, &l3->slabs_free);
 			}

Re: Random panics seen in 2.6.18-rc1

[Andrew Morton]

On Thu, 13 Jul 2006 09:12:21 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> Chandra Seetharaman reported SLAB crashes caused by the slab.c
> lock annotation patch. There is only one chunk of that patch
> that has a material effect on the slab logic - this patch
> undoes that chunk.
> 

yup.

> ---
>  mm/slab.c |    9 ---------
>  1 file changed, 9 deletions(-)
> 
> Index: linux/mm/slab.c
> ===================================================================
> --- linux.orig/mm/slab.c
> +++ linux/mm/slab.c
> @@ -3100,16 +3100,7 @@ static void free_block(struct kmem_cache
>  		if (slabp->inuse == 0) {
>  			if (l3->free_objects > l3->free_limit) {
>  				l3->free_objects -= cachep->num;
> -				/*
> -				 * It is safe to drop the lock. The slab is
> -				 * no longer linked to the cache. cachep
> -				 * cannot disappear - we are using it and
> -				 * all destruction of caches must be
> -				 * serialized properly by the user.
> -				 */
> -				spin_unlock(&l3->list_lock);
>  				slab_destroy(cachep, slabp);
> -				spin_lock(&l3->list_lock);

But what was that change _for_?  Presumably, to plug some lockdep problem. 
Which now will come back.

And the additional arg to __cache_free() was rather a step backwards - this
is fastpath.  With a bit more effort that could have been avoided (please).

Re: Random panics seen in 2.6.18-rc1

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> On Thu, 13 Jul 2006 09:12:21 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > Chandra Seetharaman reported SLAB crashes caused by the slab.c
> > lock annotation patch. There is only one chunk of that patch
> > that has a material effect on the slab logic - this patch
> > undoes that chunk.
> > 
> 
> yup.
> 
> > ---
> >  mm/slab.c |    9 ---------
> >  1 file changed, 9 deletions(-)
> > 
> > Index: linux/mm/slab.c
> > ===================================================================
> > --- linux.orig/mm/slab.c
> > +++ linux/mm/slab.c
> > @@ -3100,16 +3100,7 @@ static void free_block(struct kmem_cache
> >  		if (slabp->inuse == 0) {
> >  			if (l3->free_objects > l3->free_limit) {
> >  				l3->free_objects -= cachep->num;
> > -				/*
> > -				 * It is safe to drop the lock. The slab is
> > -				 * no longer linked to the cache. cachep
> > -				 * cannot disappear - we are using it and
> > -				 * all destruction of caches must be
> > -				 * serialized properly by the user.
> > -				 */
> > -				spin_unlock(&l3->list_lock);
> >  				slab_destroy(cachep, slabp);
> > -				spin_lock(&l3->list_lock);
> 
> But what was that change _for_?  Presumably, to plug some lockdep 
> problem. Which now will come back.

correct - but i first wanted to get the fix out, before trying to fix 
the lockdep thing.

> And the additional arg to __cache_free() was rather a step backwards - 
> this is fastpath.  With a bit more effort that could have been avoided 
> (please).

yeah, i'll fix this. Any suggestions of how to avoid the parameter 
passing? (without ugly #ifdeffery)

	Ingo

Re: Random panics seen in 2.6.18-rc1

[Andrew Morton]

On Thu, 13 Jul 2006 09:26:35 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > 
> > But what was that change _for_?  Presumably, to plug some lockdep 
> > problem. Which now will come back.
> 
> correct - but i first wanted to get the fix out, before trying to fix 
> the lockdep thing.

More yup.

> > And the additional arg to __cache_free() was rather a step backwards - 
> > this is fastpath.  With a bit more effort that could have been avoided 
> > (please).
> 
> yeah, i'll fix this. Any suggestions of how to avoid the parameter 
> passing? (without ugly #ifdeffery)

No, I don't see a way apart from inlining __cache_free(), or inlining
cache_free_alien() into both kfree() and kmem_cache_free(), both of which
are unattractive.

Well.  One could do

	local_irq_disable();
	cachep->array[smp_processor_id()]->lockdep_nested = 1;
	__cache_free(...)
	cachep->array[smp_processor_id()]->lockdep_nested = 0;
	local_irq_enable();

then do lots of ifdeffery to make that go away if !LOCKDEP.  But sheesh.

Re: Random panics seen in 2.6.18-rc1

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > Any suggestions of how to avoid the parameter passing? (without ugly 
> > #ifdeffery)
> 
> No, I don't see a way apart from inlining __cache_free(), or inlining 
> cache_free_alien() into both kfree() and kmem_cache_free(), both of 
> which are unattractive.

furthermore, cache_free_alien() is a NOP on non-NUMA, so the cost on 
non-NUMA is really small.

but ... i think gcc ought to be able to figure out that the parameter is 
totally unused on !LOCKDEP - all functions involved are static, and we 
are using -funit-at-a-time already. That should make the parameter 
passing totally zero-cost.

	Ingo

Re: Random panics seen in 2.6.18-rc1

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> but ... i think gcc ought to be able to figure out that the parameter 
> is totally unused on !LOCKDEP - all functions involved are static, and 
> we are using -funit-at-a-time already. That should make the parameter 
> passing totally zero-cost.

hm, gcc (as of 4.1.1) doesnt seem to be able to figure that out, 
probably due to the 'nesting + 1' changing the variable.

Anyway, Arjan's nesting-type idea should solve the problem - in that 
case 'nesting + 1' becomes an identity mapping of a zero-sized variable, 
which will generate zero code.

	Ingo

Re: Random panics seen in 2.6.18-rc1

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > yeah, i'll fix this. Any suggestions of how to avoid the parameter 
> > passing? (without ugly #ifdeffery)
> 
> No, I don't see a way apart from inlining __cache_free(), or inlining 
> cache_free_alien() into both kfree() and kmem_cache_free(), both of 
> which are unattractive.

Arjan has an idea that looks nice to me: passing the nesting level via a 
special type that has zero size on non-lockdep. This means that the 
current "nesting + 1" arithmetics has to be turned into something like: 
lockdep_deeper_nesting(var), and that all explicit uses of '0' have to 
become symbolic - the former is acceptable and the later is desirable. 
This could possibly also be used to clean up some of the VFS-internal 
nesting. Hm?

	Ingo

[patch] lockdep: more annotations for mm/slab.c

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > yeah, i'll fix this. Any suggestions of how to avoid the parameter 
> > > passing? (without ugly #ifdeffery)
> > 
> > No, I don't see a way apart from inlining __cache_free(), or inlining 
> > cache_free_alien() into both kfree() and kmem_cache_free(), both of 
> > which are unattractive.
> 
> Arjan has an idea that looks nice to me: passing the nesting level via 
> a special type that has zero size on non-lockdep. This means that the 
> current "nesting + 1" arithmetics has to be turned into something 
> like: lockdep_deeper_nesting(var), and that all explicit uses of '0' 
> have to become symbolic - the former is acceptable and the later is 
> desirable. This could possibly also be used to clean up some of the 
> VFS-internal nesting. Hm?

i'll work on that cleanup, but meanwhile could we apply the patch below, 
to fix the false positive? This patch (ontop of the slab.c fix-patch) 
should put us where we were before wrt lockdep, sans the spin-unlocking 
side-effect.

	Ingo

---------------->
Subject: lockdep: more annotations for mm/slab.c
From: Ingo Molnar <mingo@elte.hu>

the SLAB code can hold multiple slab locks at once,
for example at:

 [<c0105dd5>] show_trace+0xd/0x10
 [<c0105def>] dump_stack+0x17/0x1c
 [<c014182e>] __lock_acquire+0x7ab/0xa0e
 [<c0141d6e>] lock_acquire+0x5e/0x80
 [<c10b0d8e>] _spin_lock_nested+0x26/0x37
 [<c017178b>] __cache_free+0x30d/0x3d2
 [<c0171200>] slab_destroy+0xfd/0x11d
 [<c0171360>] free_block+0x140/0x17d
 [<c01717dd>] __cache_free+0x35f/0x3d2
 [<c01718cd>] kfree+0x7d/0x9a
 [<c0127889>] free_task+0xe/0x24
 [<c0127ee8>] __put_task_struct+0xc2/0xc7
 [<c012bc8f>] delayed_put_task_struct+0x1e/0x20
 [<c0139d94>] __rcu_process_callbacks+0xff/0x15d
 [<c0139e1a>] rcu_process_callbacks+0x28/0x40
 [<c012f125>] tasklet_action+0x6e/0xd1
 [<c012f2c7>] __do_softirq+0x6e/0xec
 [<c01061b7>] do_softirq+0x61/0xc7

so add the 'nested' parameter to the affected functions.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 mm/slab.c |   45 +++++++++++++++++++++++++--------------------
 1 file changed, 25 insertions(+), 20 deletions(-)

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -312,7 +312,7 @@ struct kmem_list3 __initdata initkmem_li
 static int drain_freelist(struct kmem_cache *cache,
 			struct kmem_list3 *l3, int tofree);
 static void free_block(struct kmem_cache *cachep, void **objpp, int len,
-			int node);
+		       int node, int nesting);
 static void enable_cpucache(struct kmem_cache *cachep);
 static void cache_reap(void *unused);
 
@@ -981,7 +981,7 @@ static void __drain_alien_cache(struct k
 		if (rl3->shared)
 			transfer_objects(rl3->shared, ac, ac->limit);
 
-		free_block(cachep, ac->entry, ac->avail, node);
+		free_block(cachep, ac->entry, ac->avail, node, 0);
 		ac->avail = 0;
 		spin_unlock(&rl3->list_lock);
 	}
@@ -1048,9 +1048,10 @@ static inline int cache_free_alien(struc
 		alien->entry[alien->avail++] = objp;
 		spin_unlock(&alien->lock);
 	} else {
-		spin_lock(&(cachep->nodelists[nodeid])->list_lock);
-		free_block(cachep, &objp, 1, nodeid);
-		spin_unlock(&(cachep->nodelists[nodeid])->list_lock);
+		spin_lock_nested(&cachep->nodelists[nodeid]->list_lock,
+				 nesting);
+		free_block(cachep, &objp, 1, nodeid, nesting + 1);
+		spin_unlock(&cachep->nodelists[nodeid]->list_lock);
 	}
 	return 1;
 }
@@ -1208,7 +1209,8 @@ static int __devinit cpuup_callback(stru
 			/* Free limit for this kmem_list3 */
 			l3->free_limit -= cachep->batchcount;
 			if (nc)
-				free_block(cachep, nc->entry, nc->avail, node);
+				free_block(cachep, nc->entry, nc->avail,
+					   node, 0);
 
 			if (!cpus_empty(mask)) {
 				spin_unlock_irq(&l3->list_lock);
@@ -1218,7 +1220,7 @@ static int __devinit cpuup_callback(stru
 			shared = l3->shared;
 			if (shared) {
 				free_block(cachep, l3->shared->entry,
-					   l3->shared->avail, node);
+					   l3->shared->avail, node, 0);
 				l3->shared = NULL;
 			}
 
@@ -1771,7 +1773,8 @@ static void __cache_free(struct kmem_cac
  * Before calling the slab must have been unlinked from the cache.  The
  * cache-lock is not held/needed.
  */
-static void slab_destroy(struct kmem_cache *cachep, struct slab *slabp)
+static void slab_destroy(struct kmem_cache *cachep, struct slab *slabp,
+			 int nesting)
 {
 	void *addr = slabp->s_mem - slabp->colouroff;
 
@@ -1793,7 +1796,7 @@ static void slab_destroy(struct kmem_cac
 			 * ac->lock, so pass in a nesting flag:
 			 */
 			local_irq_save(flags);
-			__cache_free(cachep->slabp_cache, slabp, 1);
+			__cache_free(cachep->slabp_cache, slabp, nesting + 1);
 			local_irq_restore(flags);
 		}
 	}
@@ -2249,7 +2252,7 @@ static void do_drain(void *arg)
 	check_irq_off();
 	ac = cpu_cache_get(cachep);
 	spin_lock(&cachep->nodelists[node]->list_lock);
-	free_block(cachep, ac->entry, ac->avail, node);
+	free_block(cachep, ac->entry, ac->avail, node, 0);
 	spin_unlock(&cachep->nodelists[node]->list_lock);
 	ac->avail = 0;
 }
@@ -2308,7 +2311,7 @@ static int drain_freelist(struct kmem_ca
 		 */
 		l3->free_objects -= cache->num;
 		spin_unlock_irq(&l3->list_lock);
-		slab_destroy(cache, slabp);
+		slab_destroy(cache, slabp, 0);
 		nr_freed++;
 	}
 out:
@@ -3077,7 +3080,7 @@ done:
  * Caller needs to acquire correct kmem_list's list_lock
  */
 static void free_block(struct kmem_cache *cachep, void **objpp, int nr_objects,
-		       int node)
+		       int node, int nesting)
 {
 	int i;
 	struct kmem_list3 *l3;
@@ -3100,7 +3103,7 @@ static void free_block(struct kmem_cache
 		if (slabp->inuse == 0) {
 			if (l3->free_objects > l3->free_limit) {
 				l3->free_objects -= cachep->num;
-				slab_destroy(cachep, slabp);
+				slab_destroy(cachep, slabp, nesting);
 			} else {
 				list_add(&slabp->list, &l3->slabs_free);
 			}
@@ -3114,7 +3117,8 @@ static void free_block(struct kmem_cache
 	}
 }
 
-static void cache_flusharray(struct kmem_cache *cachep, struct array_cache *ac)
+static void cache_flusharray(struct kmem_cache *cachep, struct array_cache *ac,
+			     int nesting)
 {
 	int batchcount;
 	struct kmem_list3 *l3;
@@ -3126,7 +3130,7 @@ static void cache_flusharray(struct kmem
 #endif
 	check_irq_off();
 	l3 = cachep->nodelists[node];
-	spin_lock_nested(&l3->list_lock, SINGLE_DEPTH_NESTING);
+	spin_lock_nested(&l3->list_lock, nesting);
 	if (l3->shared) {
 		struct array_cache *shared_array = l3->shared;
 		int max = shared_array->limit - shared_array->avail;
@@ -3140,7 +3144,7 @@ static void cache_flusharray(struct kmem
 		}
 	}
 
-	free_block(cachep, ac->entry, batchcount, node);
+	free_block(cachep, ac->entry, batchcount, node, nesting);
 free_done:
 #if STATS
 	{
@@ -3185,7 +3189,7 @@ static void __cache_free(struct kmem_cac
 		return;
 	} else {
 		STATS_INC_FREEMISS(cachep);
-		cache_flusharray(cachep, ac);
+		cache_flusharray(cachep, ac, nesting);
 		ac->entry[ac->avail++] = objp;
 	}
 }
@@ -3512,7 +3516,7 @@ static int alloc_kmemlist(struct kmem_ca
 
 			if (shared)
 				free_block(cachep, shared->entry,
-						shared->avail, node);
+					   shared->avail, node, 0);
 
 			l3->shared = new_shared;
 			if (!l3->alien) {
@@ -3611,7 +3615,8 @@ static int do_tune_cpucache(struct kmem_
 		if (!ccold)
 			continue;
 		spin_lock_irq(&cachep->nodelists[cpu_to_node(i)]->list_lock);
-		free_block(cachep, ccold->entry, ccold->avail, cpu_to_node(i));
+		free_block(cachep, ccold->entry, ccold->avail,
+			   cpu_to_node(i), 0);
 		spin_unlock_irq(&cachep->nodelists[cpu_to_node(i)]->list_lock);
 		kfree(ccold);
 	}
@@ -3700,7 +3705,7 @@ void drain_array(struct kmem_cache *cach
 			tofree = force ? ac->avail : (ac->limit + 4) / 5;
 			if (tofree > ac->avail)
 				tofree = (ac->avail + 1) / 2;
-			free_block(cachep, ac->entry, tofree, node);
+			free_block(cachep, ac->entry, tofree, node, 0);
 			ac->avail -= tofree;
 			memmove(ac->entry, &(ac->entry[tofree]),
 				sizeof(void *) * ac->avail);

Re: [patch] lockdep: more annotations for mm/slab.c

[Andrew Morton]

On Thu, 13 Jul 2006 10:46:13 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> the SLAB code can hold multiple slab locks at once,
> for example at:
> 
>  [<c0105dd5>] show_trace+0xd/0x10
>  [<c0105def>] dump_stack+0x17/0x1c
>  [<c014182e>] __lock_acquire+0x7ab/0xa0e
>  [<c0141d6e>] lock_acquire+0x5e/0x80
>  [<c10b0d8e>] _spin_lock_nested+0x26/0x37
>  [<c017178b>] __cache_free+0x30d/0x3d2
>  [<c0171200>] slab_destroy+0xfd/0x11d
>  [<c0171360>] free_block+0x140/0x17d
>  [<c01717dd>] __cache_free+0x35f/0x3d2
>  [<c01718cd>] kfree+0x7d/0x9a
>  [<c0127889>] free_task+0xe/0x24
>  [<c0127ee8>] __put_task_struct+0xc2/0xc7
>  [<c012bc8f>] delayed_put_task_struct+0x1e/0x20
>  [<c0139d94>] __rcu_process_callbacks+0xff/0x15d
>  [<c0139e1a>] rcu_process_callbacks+0x28/0x40
>  [<c012f125>] tasklet_action+0x6e/0xd1
>  [<c012f2c7>] __do_softirq+0x6e/0xec
>  [<c01061b7>] do_softirq+0x61/0xc7
> 
> so add the 'nested' parameter to the affected functions.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  mm/slab.c |   45 +++++++++++++++++++++++++--------------------

geeze, what fuss.  Can't we just tell lockdep "the locking here is correct,
so buzz off"?

Re: [patch] lockdep: more annotations for mm/slab.c

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > ---
> >  mm/slab.c |   45 +++++++++++++++++++++++++--------------------
> 
> geeze, what fuss.  Can't we just tell lockdep "the locking here is 
> correct, so buzz off"?

well, lockdep already found a locking bug in slab.c, so by telling 
lockdep to buzz off we lose the proof of correctness :-)

but i agree that this is getting a bit too intrusive. This patch is 
really just another expression of: 'slab locking is too complex', but i 
digress. Not all hope is lost though: Arjan thinks he can do a much 
simpler annotation.

	Ingo

Re: [patch] lockdep: more annotations for mm/slab.c

[Arjan van de Ven]

On Thu, 2006-07-13 at 11:18 +0200, Ingo Molnar wrote:
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > ---
> > >  mm/slab.c |   45 +++++++++++++++++++++++++--------------------
> > 
> > geeze, what fuss.  Can't we just tell lockdep "the locking here is 
> > correct, so buzz off"?
> 
> well, lockdep already found a locking bug in slab.c, so by telling 
> lockdep to buzz off we lose the proof of correctness :-)
> 
> but i agree that this is getting a bit too intrusive. This patch is 
> really just another expression of: 'slab locking is too complex', but i 
> digress. Not all hope is lost though: Arjan thinks he can do a much 
> simpler annotation.


I am hoping I can get away with just this patch; the idea is to give the
cache_cache slab a special lock type since it'll be nested all the time
(and has a natural ordering due to it's special position in the slab
code). I'm not yet sure I found all places where this stuff is
initialized (the slab code has gotten terribly complex with all the numa
stuff added to it); I've started to test this now at least and so far it
seems to work on my test box.


Index: linux-2.6.18-rc1/mm/slab.c
===================================================================
--- linux-2.6.18-rc1.orig/mm/slab.c
+++ linux-2.6.18-rc1/mm/slab.c
@@ -317,6 +317,16 @@ static void enable_cpucache(struct kmem_
 static void cache_reap(void *unused);
 
 /*
+ * Slab sometimes uses the kmalloc slabs to store the slab headers
+ * for other slabs "off slab".
+ * The locking for this is tricky in that it
+ * nests within the locks of all other slabs in a few
+ * places; to deal with this special locking we give
+ * this one slab a special class.
+ */
+static struct lock_class_key slab_name_lock_key;
+
+/*
  * This function must be completely optimized away if a constant is passed to
  * it.  Mostly the same as what is in linux/slab.h except it returns an index.
  */
@@ -1443,6 +1453,7 @@ void __init kmem_cache_init(void)
 		/* Replace the static kmem_list3 structures for the boot cpu */
 		init_list(&cache_cache, &initkmem_list3[CACHE_CACHE],
 			  numa_node_id());
+		lockdep_set_class(&(cache_cache.nodelists[numa_node_id()]->list_lock), &slab_name_lock_key);
 
 		for_each_online_node(node) {
 			init_list(malloc_sizes[INDEX_AC].cs_cachep,

Re: [patch] lockdep: more annotations for mm/slab.c

[Arjan van de Ven]

On Thu, 2006-07-13 at 12:44 +0200, Arjan van de Ven wrote:
> On Thu, 2006-07-13 at 11:18 +0200, Ingo Molnar wrote:
> > * Andrew Morton <akpm@osdl.org> wrote:
> > 
> > > > ---
> > > >  mm/slab.c |   45 +++++++++++++++++++++++++--------------------
> > > 
> > > geeze, what fuss.  Can't we just tell lockdep "the locking here is 
> > > correct, so buzz off"?
> > 
> > well, lockdep already found a locking bug in slab.c, so by telling 
> > lockdep to buzz off we lose the proof of correctness :-)
> > 
> > but i agree that this is getting a bit too intrusive. This patch is 
> > really just another expression of: 'slab locking is too complex', but i 
> > digress. Not all hope is lost though: Arjan thinks he can do a much 
> > simpler annotation.
> 
> 
> I am hoping I can get away with just this patch; the idea is to give the
> cache_cache slab a special lock type since it'll be nested all the time
> (and has a natural ordering due to it's special position in the slab
> code). I'm not yet sure I found all places where this stuff is
> initialized (the slab code has gotten terribly complex with all the numa
> stuff added to it); I've started to test this now at least and so far it
> seems to work on my test box.
> 

fwiw the slab where off-slab datastructures get stored needs this
treatment as well, I've yet to decipher the slab code where this slab is
though ;)

[patch] lockdep: undo mm/slab.c annotation

[Ingo Molnar]

Subject: lockdep: undo mm/slab.c annotation
From: Ingo Molnar <mingo@elte.hu>

undo existing mm/slab.c lock-validator annotations, in preparation
of a new, less intrusive annotation patch.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
 mm/slab.c |   33 ++++++++++-----------------------
 1 file changed, 10 insertions(+), 23 deletions(-)

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -1021,8 +1021,7 @@ static void drain_alien_cache(struct kme
 	}
 }
 
-static inline int cache_free_alien(struct kmem_cache *cachep, void *objp,
-				   int nesting)
+static inline int cache_free_alien(struct kmem_cache *cachep, void *objp)
 {
 	struct slab *slabp = virt_to_slab(objp);
 	int nodeid = slabp->nodeid;
@@ -1040,7 +1039,7 @@ static inline int cache_free_alien(struc
 	STATS_INC_NODEFREES(cachep);
 	if (l3->alien && l3->alien[nodeid]) {
 		alien = l3->alien[nodeid];
-		spin_lock_nested(&alien->lock, nesting);
+		spin_lock(&alien->lock);
 		if (unlikely(alien->avail == alien->limit)) {
 			STATS_INC_ACOVERFLOW(cachep);
 			__drain_alien_cache(cachep, alien, nodeid);
@@ -1069,8 +1068,7 @@ static inline void free_alien_cache(stru
 {
 }
 
-static inline int cache_free_alien(struct kmem_cache *cachep, void *objp,
-				   int nesting)
+static inline int cache_free_alien(struct kmem_cache *cachep, void *objp)
 {
 	return 0;
 }
@@ -1760,8 +1758,6 @@ static void slab_destroy_objs(struct kme
 }
 #endif
 
-static void __cache_free(struct kmem_cache *cachep, void *objp, int nesting);
-
 /**
  * slab_destroy - destroy and release all objects in a slab
  * @cachep: cache pointer being destroyed
@@ -1785,17 +1781,8 @@ static void slab_destroy(struct kmem_cac
 		call_rcu(&slab_rcu->head, kmem_rcu_free);
 	} else {
 		kmem_freepages(cachep, addr);
-		if (OFF_SLAB(cachep)) {
-			unsigned long flags;
-
-			/*
-		 	 * lockdep: we may nest inside an already held
-			 * ac->lock, so pass in a nesting flag:
-			 */
-			local_irq_save(flags);
-			__cache_free(cachep->slabp_cache, slabp, 1);
-			local_irq_restore(flags);
-		}
+		if (OFF_SLAB(cachep))
+			kmem_cache_free(cachep->slabp_cache, slabp);
 	}
 }
 
@@ -3126,7 +3113,7 @@ static void cache_flusharray(struct kmem
 #endif
 	check_irq_off();
 	l3 = cachep->nodelists[node];
-	spin_lock_nested(&l3->list_lock, SINGLE_DEPTH_NESTING);
+	spin_lock(&l3->list_lock);
 	if (l3->shared) {
 		struct array_cache *shared_array = l3->shared;
 		int max = shared_array->limit - shared_array->avail;
@@ -3169,14 +3156,14 @@ free_done:
  * Release an obj back to its cache. If the obj has a constructed state, it must
  * be in this state _before_ it is released.  Called with disabled ints.
  */
-static void __cache_free(struct kmem_cache *cachep, void *objp, int nesting)
+static inline void __cache_free(struct kmem_cache *cachep, void *objp)
 {
 	struct array_cache *ac = cpu_cache_get(cachep);
 
 	check_irq_off();
 	objp = cache_free_debugcheck(cachep, objp, __builtin_return_address(0));
 
-	if (cache_free_alien(cachep, objp, nesting))
+	if (cache_free_alien(cachep, objp))
 		return;
 
 	if (likely(ac->avail < ac->limit)) {
@@ -3415,7 +3402,7 @@ void kmem_cache_free(struct kmem_cache *
 	BUG_ON(virt_to_cache(objp) != cachep);
 
 	local_irq_save(flags);
-	__cache_free(cachep, objp, 0);
+	__cache_free(cachep, objp);
 	local_irq_restore(flags);
 }
 EXPORT_SYMBOL(kmem_cache_free);
@@ -3440,7 +3427,7 @@ void kfree(const void *objp)
 	kfree_debugcheck(objp);
 	c = virt_to_cache(objp);
 	debug_check_no_locks_freed(objp, obj_size(c));
-	__cache_free(c, (void *)objp, 0);
+	__cache_free(c, (void *)objp);
 	local_irq_restore(flags);
 }
 EXPORT_SYMBOL(kfree);

[patch] lockdep: annotate mm/slab.c

[Ingo Molnar]

Subject: lockdep: annotate mm/slab.c
From: Arjan van de Ven <arjan@infradead.org>

mm/slab.c uses nested locking when dealing with 'off-slab'
caches, in that case it allocates the slab header from the
(on-slab) kmalloc caches. Teach the lock validator about
this by putting all on-slab caches into a separate class.

this patch has no effect on non-lockdep kernels.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 mm/slab.c |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -674,6 +674,37 @@ static struct kmem_cache cache_cache = {
 #endif
 };
 
+#ifdef CONFIG_LOCKDEP
+
+/*
+ * Slab sometimes uses the kmalloc slabs to store the slab headers
+ * for other slabs "off slab".
+ * The locking for this is tricky in that it nests within the locks
+ * of all other slabs in a few places; to deal with this special
+ * locking we put on-slab caches into a separate lock-class.
+ */
+static struct lock_class_key on_slab_key;
+
+static inline void init_lock_keys(struct cache_sizes *s)
+{
+	int q;
+
+	for (q = 0; q < MAX_NUMNODES; q++) {
+		if (!s->cs_cachep->nodelists[q] || OFF_SLAB(s->cs_cachep))
+			continue;
+		lockdep_set_class(&s->cs_cachep->nodelists[q]->list_lock,
+				  &on_slab_key);
+	}
+}
+
+#else
+static inline void init_lock_keys(struct cache_sizes *s)
+{
+}
+#endif
+
+
+
 /* Guard access to the cache-chain. */
 static DEFINE_MUTEX(cache_chain_mutex);
 static struct list_head cache_chain;
@@ -1391,6 +1422,7 @@ void __init kmem_cache_init(void)
 					ARCH_KMALLOC_FLAGS|SLAB_PANIC,
 					NULL, NULL);
 		}
+		init_lock_keys(sizes);
 
 		sizes->cs_dmacachep = kmem_cache_create(names->name_dma,
 					sizes->cs_size,

Re: [patch] lockdep: annotate mm/slab.c

[Pekka Enberg]

Hi,

On 7/13/06, Ingo Molnar <mingo@elte.hu> wrote:
> mm/slab.c uses nested locking when dealing with 'off-slab'
> caches, in that case it allocates the slab header from the
> (on-slab) kmalloc caches. Teach the lock validator about
> this by putting all on-slab caches into a separate class.

Which lock is that? This affects only caches that cache_grow() use, so
we are really only interested in annotating kmalloc() on-slab caches
(like in the patch), not _all_, right?

Re: [patch] lockdep: annotate mm/slab.c

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Hi,
> 
> On 7/13/06, Ingo Molnar <mingo@elte.hu> wrote:
> >mm/slab.c uses nested locking when dealing with 'off-slab'
> >caches, in that case it allocates the slab header from the
> >(on-slab) kmalloc caches. Teach the lock validator about
> >this by putting all on-slab caches into a separate class.
> 
> Which lock is that? This affects only caches that cache_grow() use, so 
> we are really only interested in annotating kmalloc() on-slab caches 
> (like in the patch), not _all_, right?

it's ->list_lock, and a sample nesting scenario is:

 [<c013a9a8>] lock_acquire+0x78/0xa0
 [<c0313e5a>] _spin_lock_nested+0x2a/0x40
 [<c0163024>] __cache_free+0x484/0x5c0
 [<c01632ad>] slab_destroy+0x14d/0x1e0
 [<c0162ac9>] free_block+0x189/0x1e0
 [<c01630f4>] __cache_free+0x554/0x5c0
 [<c0163653>] kmem_cache_free+0x73/0xc0
 [<c016a24f>] file_free_rcu+0xf/0x20
 [<c0130755>] __rcu_process_callbacks+0x75/0x1b0
 [<c0130bc7>] rcu_process_callbacks+0x27/0x50
 [<c0123f3a>] tasklet_action+0x6a/0xf0
 [<c012413b>] __do_softirq+0x8b/0x130
 [<c0106ba3>] do_softirq+0x73/0x100

(the off-slab nesting is perfectly correct locking code AFAICS - it just 
needs to be taught to lockdep - which the patch does. OTOH i'm less sure 
about the NUMA alien-cache-draining nesting.)

	Ingo

Re: [patch] lockdep: annotate mm/slab.c

[Pekka Enberg]

On 7/13/06, Ingo Molnar <mingo@elte.hu> wrote:
> mm/slab.c uses nested locking when dealing with 'off-slab'
> caches, in that case it allocates the slab header from the
> (on-slab) kmalloc caches. Teach the lock validator about
> this by putting all on-slab caches into a separate class.

What's "nested lock" btw? If I understood from the other patch, you're
talking about ac->lock. Surely you can't take the same lock twice but
it's perfectly legal to take lock as long as the ac instance is
different...

Re: [patch] lockdep: annotate mm/slab.c

[Linus Torvalds]

On Thu, 13 Jul 2006, Pekka Enberg wrote:
> 
> What's "nested lock" btw? If I understood from the other patch, you're
> talking about ac->lock. Surely you can't take the same lock twice but
> it's perfectly legal to take lock as long as the ac instance is
> different...

Normally, no. You can't take another lock just because the instance is 
different. That causes ABBA deadlocks unless you have some underlying 
_ordering_ of the different lock instances.

		Linus

Re: [patch] lockdep: annotate mm/slab.c

[Arjan van de Ven]

On Thu, 2006-07-13 at 11:56 -0700, Linus Torvalds wrote:
> 
> On Thu, 13 Jul 2006, Pekka Enberg wrote:
> > 
> > What's "nested lock" btw? If I understood from the other patch, you're
> > talking about ac->lock. Surely you can't take the same lock twice but
> > it's perfectly legal to take lock as long as the ac instance is
> > different...
> 
> Normally, no. You can't take another lock just because the instance is 
> different. That causes ABBA deadlocks unless you have some underlying 
> _ordering_ of the different lock instances.

and that is the case here fwiw;
the OFF_SLAB metadata thing is tricky when freeing stuff:

for kfree() you take the lock for your own slab, do some management and
then do effectively do a kfree() on your off-slab metadata. Which then
takes the lock for the kmalloc slab of the size of your metadata.
This is a natural order, you assume (and pray) that this kmalloc slab is
not in itself a slab with off-slab metadata, so that there can't be a BA
of the ABBA deadlock. [*]

This is what needed the lockdep annotation; lockdep by default thinks
all slabs are equal (by virtue of sharing the spin_lock_init()
location). And because of the slab-internal knowledge of off-slab versus
not-off-slab they're not equal.

Now there are two choices for annotation: tell the spin lock aquisition
that there is a natural hierarchy (eg spin_lock_depends) and this is
what Ingo tried at first. Except that it got horribly complex, messy and
just outright gross.

The second option is telling lockdep that kmalloc slabs without off-slab
metadata are really different in terms of locking rules (eg they have a
separate identity than the other slabs); and that is why my patch does
(or at least tries to; it works for my machines but the slab
initialization code is horribly complex wrt hotplug and numa so I may
have missed a corner case initialization). 

The downside of this 'separate identity' is that you basically split the
lock history, meaning that the graph of past history is not built up as
fast as it could have been. Slab is used so much that that isn't a big
deal; for other more exotic cases that's more of a quality issue.

Greetings,
   Arjan van de Ven


[*] Note Note Note
there is a corner case in the slab code that I personally don't trust at
all. In the NUMA case, if the memory is not originally from your own
node, the cache_free_alien() function takes, while having your own local
lock, the lock of the remote node as well. (at least on my reading of
the code) to free the memory to that node. I have yet to see where in
the code it safeguards against that remote node doing the exact same
thing in the opposite direction concurrently, and causing a basic ABBA
deadlock.

Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter]

On Thu, 13 Jul 2006, Arjan van de Ven wrote:

> there is a corner case in the slab code that I personally don't trust at
> all. In the NUMA case, if the memory is not originally from your own
> node, the cache_free_alien() function takes, while having your own local
> lock, the lock of the remote node as well. (at least on my reading of
> the code) to free the memory to that node. I have yet to see where in
> the code it safeguards against that remote node doing the exact same
> thing in the opposite direction concurrently, and causing a basic ABBA
> deadlock.

Hmmm.. This case is only followed during bootup when we do not have
alien caches yet. And its pretty rare to free memory on bootup. Once the
alien caches are present then we do not take the listlock anymore but
use the lock of the alien structure.

This could cause an ABBA deadlock if a free happens on another 
processor during bootup before all the slabs are established.

That then brings us to look if a slab free can happen before a slab is 
completely established via kmem_cache_create.

kmem_cache_create takes the cpu hotplug lock and the cache_chain_mutex.

One could argue that a subsystem must make sure that the slab cache it 
creates should not be used before kmem_cache_create is complete?

Alokk: Do we really need to check for alien caches not present there?

Re: [patch] lockdep: annotate mm/slab.c

[Alok kataria]

Hi,
On 7/13/06, Christoph Lameter <clameter@sgi.com> wrote:
> On Thu, 13 Jul 2006, Arjan van de Ven wrote:
>
> > there is a corner case in the slab code that I personally don't trust at
> > all. In the NUMA case, if the memory is not originally from your own
> > node, the cache_free_alien() function takes, while having your own local
> > lock, the lock of the remote node as well. (at least on my reading of
> > the code) to free the memory to that node. I have yet to see where in
> > the code it safeguards against that remote node doing the exact same
> > thing in the opposite direction concurrently, and causing a basic ABBA
> > deadlock.
>
> Hmmm.. This case is only followed during bootup when we do not have
> alien caches yet. And its pretty rare to free memory on bootup. Once the
> alien caches are present then we do not take the listlock anymore but
> use the lock of the alien structure.
>

Christoph, IMO even then we wont deadlock, because in the case of a
remote free when there are no alien caches, we simply take the remote
node's list_lock and free the object, directly in the remote slab.

> This could cause an ABBA deadlock if a free happens on another
> processor during bootup before all the slabs are established.
>
> That then brings us to look if a slab free can happen before a slab is
> completely established via kmem_cache_create.
>
> kmem_cache_create takes the cpu hotplug lock and the cache_chain_mutex.
>
> One could argue that a subsystem must make sure that the slab cache it
> creates should not be used before kmem_cache_create is complete?
>
> Alokk: Do we really need to check for alien caches not present there?
>

Yes we do need to, there can be a case when all cpu's of a node have
gone down, we free the alien cache, and this alien cache might have
come from this cache itself, (see cpuup_callback).  In this case we
will find the alien caches to be absent and then we will directly free
to the remote nodes slab.


Thanks & Regards,
Alok
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
A computer scientist is someone who, when told to "Go to Hell," sees
the "go to," rather than the destination, as harmful.

Alok Kataria

Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter]

On Thu, 13 Jul 2006, Arjan van de Ven wrote:

> [*] Note Note Note
> there is a corner case in the slab code that I personally don't trust at
> all. In the NUMA case, if the memory is not originally from your own
> node, the cache_free_alien() function takes, while having your own local
> lock, the lock of the remote node as well. (at least on my reading of
> the code) to free the memory to that node. I have yet to see where in
> the code it safeguards against that remote node doing the exact same
> thing in the opposite direction concurrently, and causing a basic ABBA
> deadlock.

Second look: I cannot find where we take our own local nodes list_lock.
We only take the lock from the remote node. Or is this related to the 
OFF_SLAB kfree issue?


We either have a alien cache structure established then:

We take a lock on the alien structure for node x from our own node 
(without holding our local list_lock!) and then we need take the remote 
list_lock for node x if the alien structure overflows and we then free
to the remote nodes list.

Or we do not have a alien cache structure established yet. Then:

We simply take the remote list_lock on node x and free directly to the 
foreign nodes list.



In an OFF_SLAB situation this may differ because then we call 
kmem_cache_free from slab_destroy. Ughhh... This looks extremely bad. 
Whew! We drop the list lock before calling slab_destroy.

Re: [patch] lockdep: annotate mm/slab.c

[Andrew Morton]

On Thu, 13 Jul 2006 15:51:09 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> On Thu, 13 Jul 2006, Arjan van de Ven wrote:
> 
> > [*] Note Note Note
> > there is a corner case in the slab code that I personally don't trust at
> > all. In the NUMA case, if the memory is not originally from your own
> > node, the cache_free_alien() function takes, while having your own local
> > lock, the lock of the remote node as well. (at least on my reading of
> > the code) to free the memory to that node. I have yet to see where in
> > the code it safeguards against that remote node doing the exact same
> > thing in the opposite direction concurrently, and causing a basic ABBA
> > deadlock.
> 
> Second look: I cannot find where we take our own local nodes list_lock.
> We only take the lock from the remote node. Or is this related to the 
> OFF_SLAB kfree issue?
> 
> 
> We either have a alien cache structure established then:
> 
> We take a lock on the alien structure for node x from our own node 
> (without holding our local list_lock!) and then we need take the remote 
> list_lock for node x if the alien structure overflows and we then free
> to the remote nodes list.
> 
> Or we do not have a alien cache structure established yet. Then:
> 
> We simply take the remote list_lock on node x and free directly to the 
> foreign nodes list.
> 
> 
> 
> In an OFF_SLAB situation this may differ because then we call 
> kmem_cache_free from slab_destroy. Ughhh... This looks extremely bad. 

uh-oh.

> Whew! We drop the list lock before calling slab_destroy.

Well we did, up until about ten minutes ago.

free_block()'s droppage of l3->list_lock around the slab_destroy() call was
just reverted, due to Shailabh confirming that it caused corruption.

Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter]

On Thu, 13 Jul 2006, Andrew Morton wrote:

> > Whew! We drop the list lock before calling slab_destroy.
> 
> Well we did, up until about ten minutes ago.
> 
> free_block()'s droppage of l3->list_lock around the slab_destroy() call was
> just reverted, due to Shailabh confirming that it caused corruption.

How would this slab become corrupted if it is no longer on the lists?

Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter]

Could we please remove the fake revert from the git tree immediately?

http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fc818301a8a39fedd7f0a71f878f29130c72193d

2.6.17 code has also the dropping of the lock. This was no reversion. 
Maybe there is a problem but then I'd like to hear about it:

               /* fixup slab chains */
                if (slabp->inuse == 0) {
                        if (l3->free_objects > l3->free_limit) {
                                l3->free_objects -= cachep->num;
                                /*
                                 * It is safe to drop the lock. The slab is
                                 * no longer linked to the cache. cachep
                                 * cannot disappear - we are using it and
                                 * all destruction of caches must be
                                 * serialized properly by the user.
                                 */
                                spin_unlock(&l3->list_lock);
                                slab_destroy(cachep, slabp);
                                spin_lock(&l3->list_lock);
                        } else {
                                list_add(&slabp->list, &l3->slabs_free);
                        }

Re: [patch] lockdep: annotate mm/slab.c

[Andrew Morton]

On Thu, 13 Jul 2006 19:46:09 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> Could we please remove the fake revert from the git tree immediately?

Let's not do anything immediately, OK?  We're thrashing around here.

> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fc818301a8a39fedd7f0a71f878f29130c72193d

Not fake - it's a partial reversion of 
2b2d5493e10051694ae3a57ea6a153e3cb4d4488

> 2.6.17 code has also the dropping of the lock.

It doesn't.

> This was no reversion. 
> Maybe there is a problem but then I'd like to hear about it:

It's all in this thread - see Chandra's testing results.

Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter]

On Thu, 13 Jul 2006, Andrew Morton wrote:

> > 2.6.17 code has also the dropping of the lock.
> 
> It doesn't.

Ahh... mm patch in the way. This gets even stranger.
 
> > This was no reversion. 
> > Maybe there is a problem but then I'd like to hear about it:
> 
> It's all in this thread - see Chandra's testing results.

Hmmm. Chandra's traces are all over the place.

Ok. I found a series of cases where free_block is used on the shared 
array where the shared array can become corrupted if we drop the lock
in free_block():

1. cache_reap() calling drain_array (which calls free_block) on the shared 
  array

2. drain_cpu_caches() calling drain_array on the shared array.

3. cpuup_callback() in case CPU_UP_CANCELLED calling free_block

4. alloc_kmemlist() calling free_block().

The fix by removing the dropping of the lock in free_block could cause 
retaking the list_lock that we already hold in the OFF_SLAB case (even in 
the non NUMA case). 

However, we have not noticed this so far. Maybe we were lucky?

In the RCU case we only need to take the list lock when RCU runs to free 
the management object. So that is safe. Guess we never use non-RCU 
OFF_SLAB.

Alokk? Can you confirm this reasoning.

Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter]

On Thu, 13 Jul 2006, Christoph Lameter wrote:

> The fix by removing the dropping of the lock in free_block could cause 
> retaking the list_lock that we already hold in the OFF_SLAB case (even in 
> the non NUMA case). 

That retaking only occurs if the general slab cache used for the cache 
management is the same general slab where we are freeing from.

Otherwise we are acquiring the list_locks of two distinct slab caches 
which may introduce an issue of lock ordering.

So reversing the patch seems to be the right measure after all. But we 
have the two weird locking scenarios above.

Re: [patch] lockdep: annotate mm/slab.c

[Alok kataria]

On 7/13/06, Christoph Lameter <clameter@sgi.com> wrote:
> On Thu, 13 Jul 2006, Christoph Lameter wrote:
>
> > The fix by removing the dropping of the lock in free_block could cause
> > retaking the list_lock that we already hold in the OFF_SLAB case (even in
> > the non NUMA case).
>
> That retaking only occurs if the general slab cache used for the cache
> management is the same general slab where we are freeing from.
>
> Otherwise we are acquiring the list_locks of two distinct slab caches

There can be a _theoretical_ case in which we have a cache (X) which
has its slab descriptor  from another cache (Y), and this caches slab
descriptor too comes from another cache (Z) ...and so on.
In this case there can be a recursive lock issue.
But _practically_ speaking i don't think this nesting of
slab-descriptors can go down till a depth greater than 2 (because
slab-descriptors come from a array-size cache, and getting a slab
descriptor which has size greater than 1K is very rare). And this
thing forming a cycle is virtually impossible.

> which may introduce an issue of lock ordering.
>

> So reversing the patch seems to be the right measure after all. But we
> have the two weird locking scenarios above.

Yes that is the easiest way out, but let me give it a second thought.

Thanks & Regards,
Alok
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
A computer scientist is someone who, when told to "Go to Hell," sees
the "go to," rather than the destination, as harmful.

Alok Kataria

Re: [patch] lockdep: annotate mm/slab.c

[Andrew Morton]

On Thu, 13 Jul 2006 19:29:52 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> On Thu, 13 Jul 2006, Andrew Morton wrote:
> 
> > > Whew! We drop the list lock before calling slab_destroy.
> > 
> > Well we did, up until about ten minutes ago.
> > 
> > free_block()'s droppage of l3->list_lock around the slab_destroy() call was
> > just reverted, due to Shailabh confirming that it caused corruption.
> 
> How would this slab become corrupted if it is no longer on the lists?

It's a bad sign that this question is flowing in the you->me direction ;)

I don't see anywhere under slab_destroy() where *cachep state gets altered.

The change did cause
free_block->slab_destroy->__cache_free->cache_free_alien to no longer be
called under this slab's l3->list_lock.  Maybe that locking is
(accidentally?) protecting something?

Re: [patch] lockdep: annotate mm/slab.c

[Christoph Lameter]

On Thu, 13 Jul 2006, Andrew Morton wrote:

> > How would this slab become corrupted if it is no longer on the lists?
> 
> It's a bad sign that this question is flowing in the you->me direction ;)

Take it as a rhetorical question reflecting my lack of details about this 
issue.
> 
> I don't see anywhere under slab_destroy() where *cachep state gets altered.
> 
> The change did cause
> free_block->slab_destroy->__cache_free->cache_free_alien to no longer be
> called under this slab's l3->list_lock.  Maybe that locking is
> (accidentally?) protecting something?

Yes this is also protecting the shared array. It is invalid to use 
free_block on elements of the shared array. It is valid to use free block 
on per cpu arrays since they are protected only by interrupt disable. It 
also valid to use free_block on alien caches because they have their own 
lock.

Still looking.....

Re: [patch] lockdep: annotate mm/slab.c

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> On 7/13/06, Ingo Molnar <mingo@elte.hu> wrote:
> >mm/slab.c uses nested locking when dealing with 'off-slab'
> >caches, in that case it allocates the slab header from the
> >(on-slab) kmalloc caches. Teach the lock validator about
> >this by putting all on-slab caches into a separate class.
> 
> What's "nested lock" btw? If I understood from the other patch, you're 
> talking about ac->lock. Surely you can't take the same lock twice but 
> it's perfectly legal to take lock as long as the ac instance is 
> different...

yeah - there's some ambiguity of the term "nested lock". For the lock 
validator it means "holding two instances of the same lock class". A 
"lock class" is something like inode->i_mutex. (standalone static locks 
like cache_chain_mutex form their own singleton lock class. See 
Documentation/lockdep-design.txt for more details.)

"trying to lock the same lock instance twice" we call "recursive 
locking", and that's a bug for everything except read_lock() on rwlocks. 
There is no "recursive locking" in slab.c, but there is "nested 
locking". For the case of "nested locking" the lock validator needs to 
be taught of the relation between instances. Most of the cases the 
relation is "static" and can thus be assigned build-time via the use of 
separate lock-keys that "split up" a class into subclasses. In rare 
cases the relation is dynamic (for example the VFS has such nesting 
rules).

initially i annotated slab.c via dynamic nesting - but as Arjan has 
correctly observed, most of the nested locking in slab.c is of static 
type: we first take the off-slab lock, then the on-slab lock. [or we 
only take an on-slab lock, if the cache is on-slab]

Note: nested locking annotations arent just done to "shut up" lockdep, 
but rather to enable lockdep from now on to enforce this dependency 
rule: if anywhere we take an off-slab lock after an on-slab lock it will 
print a warning. That's why we go the trouble of identifying all the 
nested locking cases instead of going the easy path of "shutting lockdep 
off" (we could trivially ignore nesting within lockdep.c) - there were a 
couple of locking bugs found already that were related to nested 
locking.

btw., there's still one nested locking construct in slab.c that could 
cause problems:

 Call Trace:
  [<ffffffff8020b0b9>] show_trace+0xaa/0x23d
  [<ffffffff8020b261>] dump_stack+0x15/0x17
  [<ffffffff802456c4>] __lock_acquire+0x127/0x9c4
  [<ffffffff8024648b>] lock_acquire+0x4b/0x6a
  [<ffffffff804aead3>] _spin_lock+0x25/0x31
  [<ffffffff8027301a>] __drain_alien_cache+0x34/0x78
  [<ffffffff80272b1f>] __cache_free+0xe8/0x215
  [<ffffffff80272dc4>] slab_destroy+0x9e/0xc2
  [<ffffffff80272ed3>] free_block+0xeb/0x135
  [<ffffffff80273043>] __drain_alien_cache+0x5d/0x78
  [<ffffffff80272b1f>] __cache_free+0xe8/0x215
  [<ffffffff80273203>] kfree+0x8c/0xb0

what guarantees that while we are 'draining' another node's cache, that 
other node does not drain our cache (and thus we'd deadlock)?

	Ingo

Re: [patch] lockdep: annotate mm/slab.c

[Linus Torvalds]

On Thu, 13 Jul 2006, Ingo Molnar wrote:
>  
> +#ifdef CONFIG_LOCKDEP
> +
> +/*
> + * Slab sometimes uses the kmalloc slabs to store the slab headers
> + * for other slabs "off slab".
> + * The locking for this is tricky in that it nests within the locks
> + * of all other slabs in a few places; to deal with this special
> + * locking we put on-slab caches into a separate lock-class.
> + */
> +static struct lock_class_key on_slab_key;
> +
> +static inline void init_lock_keys(struct cache_sizes *s)
> +{
> +	int q;
> +
> +	for (q = 0; q < MAX_NUMNODES; q++) {
> +		if (!s->cs_cachep->nodelists[q] || OFF_SLAB(s->cs_cachep))
> +			continue;
> +		lockdep_set_class(&s->cs_cachep->nodelists[q]->list_lock,
> +				  &on_slab_key);
> +	}
> +}
> +
> +#else
> +static inline void init_lock_keys(struct cache_sizes *s)
> +{
> +}
> +#endif

Why isn't the "on_slab_key" local to just the init_lock_keys() function, 
and the #ifdef around it all?

Ie just

	static inline void init_lock_keys(struct cache_sizes *s)
	{
	#ifdef CONFIG_LOCKDEP
		static struct lock_class_key on_slab_key;
		int q;

		for (q = 0; q < MAX_NUMNODES; q++) {
			...
	#endif CONFIG_LOCKDEP
	}

instead?

		Linus

Re: [patch] lockdep: annotate mm/slab.c

[Arjan van de Ven]

On Thu, 2006-07-13 at 11:50 -0700, Linus Torvalds wrote:
> 
> Why isn't the "on_slab_key" local to just the init_lock_keys()
> function, 
> and the #ifdef around it all?

it's the same net results; the variable is 0 bytes in size for !LOCKDEP 

Re: [patch] lockdep: annotate mm/slab.c

[Linus Torvalds]

On Thu, 13 Jul 2006, Arjan van de Ven wrote:

> On Thu, 2006-07-13 at 11:50 -0700, Linus Torvalds wrote:
> > 
> > Why isn't the "on_slab_key" local to just the init_lock_keys()
> > function, 
> > and the #ifdef around it all?
> 
> it's the same net results; the variable is 0 bytes in size for !LOCKDEP 

That's not why I reacted. I reacted because the code is ugly, and would be 
much cleaner if it had everything in one place.

Btw, the variable size for !LOCKDEP is totally irrelevant: you need to 
have it inside the #ifdef LOCKDEP _anyway_, if only yo shut up gcc about 
unused static variables. Which you did do, by duplicating the function 
(once empty), and having an #else part to it all.

			Linus

Re: [patch] lockdep: annotate mm/slab.c

[Arjan van de Ven]

On Thu, 2006-07-13 at 12:21 -0700, Linus Torvalds wrote:
> 
> On Thu, 13 Jul 2006, Arjan van de Ven wrote:
> 
> > On Thu, 2006-07-13 at 11:50 -0700, Linus Torvalds wrote:
> > > 
> > > Why isn't the "on_slab_key" local to just the init_lock_keys()
> > > function, 
> > > and the #ifdef around it all?
> > 
> > it's the same net results; the variable is 0 bytes in size for !LOCKDEP 
> 
> That's not why I reacted. I reacted because the code is ugly, and would be 
> much cleaner if it had everything in one place.

fair enough

Re: [patch] lockdep: annotate mm/slab.c

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> Why isn't the "on_slab_key" local to just the init_lock_keys() 
> function, and the #ifdef around it all?

yeah - find updated patch below.

	Ingo

------->
Subject: lockdep: annotate mm/slab.c
From: Arjan van de Ven <arjan@infradead.org>

mm/slab.c uses nested locking when dealing with 'off-slab'
caches, in that case it allocates the slab header from the
(on-slab) kmalloc caches. Teach the lock validator about
this by putting all on-slab caches into a separate class.

this patch has no effect on non-lockdep kernels.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 mm/slab.c |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -674,6 +674,30 @@ static struct kmem_cache cache_cache = {
 #endif
 };
 
+/*
+ * Slab sometimes uses the kmalloc slabs to store the slab headers
+ * for other slabs "off slab".
+ * The locking for this is tricky in that it nests within the locks
+ * of all other slabs in a few places; to deal with this special
+ * locking we put on-slab caches into a separate lock-class.
+ */
+static inline void init_lock_keys(struct cache_sizes *s)
+{
+#ifdef CONFIG_LOCKDEP
+	static struct lock_class_key on_slab_key;
+	int q;
+
+	for (q = 0; q < MAX_NUMNODES; q++) {
+		if (!s->cs_cachep->nodelists[q] || OFF_SLAB(s->cs_cachep))
+			continue;
+		lockdep_set_class(&s->cs_cachep->nodelists[q]->list_lock,
+				  &on_slab_key);
+	}
+#endif
+}
+
+
+
 /* Guard access to the cache-chain. */
 static DEFINE_MUTEX(cache_chain_mutex);
 static struct list_head cache_chain;
@@ -1391,6 +1415,7 @@ void __init kmem_cache_init(void)
 					ARCH_KMALLOC_FLAGS|SLAB_PANIC,
 					NULL, NULL);
 		}
+		init_lock_keys(sizes);
 
 		sizes->cs_dmacachep = kmem_cache_create(names->name_dma,
 					sizes->cs_size,

Re: [patch] lockdep: annotate mm/slab.c

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > Why isn't the "on_slab_key" local to just the init_lock_keys() 
> > function, and the #ifdef around it all?
> 
> yeah - find updated patch below.

(find yet another update below - there were too many newlines added 
after the function.)

------->
Subject: lockdep: annotate mm/slab.c
From: Arjan van de Ven <arjan@infradead.org>

mm/slab.c uses nested locking when dealing with 'off-slab'
caches, in that case it allocates the slab header from the
(on-slab) kmalloc caches. Teach the lock validator about
this by putting all on-slab caches into a separate class.

this patch has no effect on non-lockdep kernels.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 mm/slab.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -674,6 +674,28 @@ static struct kmem_cache cache_cache = {
 #endif
 };
 
+/*
+ * Slab sometimes uses the kmalloc slabs to store the slab headers
+ * for other slabs "off slab".
+ * The locking for this is tricky in that it nests within the locks
+ * of all other slabs in a few places; to deal with this special
+ * locking we put on-slab caches into a separate lock-class.
+ */
+static inline void init_lock_keys(struct cache_sizes *s)
+{
+#ifdef CONFIG_LOCKDEP
+	static struct lock_class_key on_slab_key;
+	int q;
+
+	for (q = 0; q < MAX_NUMNODES; q++) {
+		if (!s->cs_cachep->nodelists[q] || OFF_SLAB(s->cs_cachep))
+			continue;
+		lockdep_set_class(&s->cs_cachep->nodelists[q]->list_lock,
+				  &on_slab_key);
+	}
+#endif
+}
+
 /* Guard access to the cache-chain. */
 static DEFINE_MUTEX(cache_chain_mutex);
 static struct list_head cache_chain;
@@ -1391,6 +1413,7 @@ void __init kmem_cache_init(void)
 					ARCH_KMALLOC_FLAGS|SLAB_PANIC,
 					NULL, NULL);
 		}
+		init_lock_keys(sizes);
 
 		sizes->cs_dmacachep = kmem_cache_create(names->name_dma,
 					sizes->cs_size,

Re: [patch] lockdep: annotate mm/slab.c

[Andrew Morton]

On Thu, 13 Jul 2006 11:50:01 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:

> 
> 
> On Thu, 13 Jul 2006, Ingo Molnar wrote:
> >  
> > +#ifdef CONFIG_LOCKDEP
> > +
> > +/*
> > + * Slab sometimes uses the kmalloc slabs to store the slab headers
> > + * for other slabs "off slab".
> > + * The locking for this is tricky in that it nests within the locks
> > + * of all other slabs in a few places; to deal with this special
> > + * locking we put on-slab caches into a separate lock-class.
> > + */
> > +static struct lock_class_key on_slab_key;
> > +
> > +static inline void init_lock_keys(struct cache_sizes *s)
> > +{
> > +	int q;
> > +
> > +	for (q = 0; q < MAX_NUMNODES; q++) {
> > +		if (!s->cs_cachep->nodelists[q] || OFF_SLAB(s->cs_cachep))
> > +			continue;
> > +		lockdep_set_class(&s->cs_cachep->nodelists[q]->list_lock,
> > +				  &on_slab_key);
> > +	}
> > +}
> > +
> > +#else
> > +static inline void init_lock_keys(struct cache_sizes *s)
> > +{
> > +}
> > +#endif
> 
> Why isn't the "on_slab_key" local to just the init_lock_keys() function, 
> and the #ifdef around it all?
> 
> Ie just
> 
> 	static inline void init_lock_keys(struct cache_sizes *s)
> 	{
> 	#ifdef CONFIG_LOCKDEP
> 		static struct lock_class_key on_slab_key;
> 		int q;
> 
> 		for (q = 0; q < MAX_NUMNODES; q++) {
> 			...
> 	#endif CONFIG_LOCKDEP
> 	}
> 
> instead?
> 

It could be wholly hidded inside a macro

#define lockdep_go_away(p) {
		static struct lock_class_key foo;
		lockdep_set_class(p, &foo);
	}

But istr suggesting that a couple of weeks ago and was given a
good-sounding reason which I forget.

At least when the code laid out as Ingo proposed, we have room for a
decent comment, which is rather desirable for this sort of thing.

Re: Random panics seen in 2.6.18-rc1

[Chandra Seetharaman]

On Thu, 2006-07-13 at 09:12 +0200, Ingo Molnar wrote:
> * Chandra Seetharaman <sekharan@us.ibm.com> wrote:
> 
> > By adding one patch at a time to 2.6.17's mm/slab.c, I found that the
> > following patch is the cause of the panic.
> > --------------
> > [PATCH] lockdep: annotate SLAB code
> 
> great debugging!

Thanks. 
> 
> I have reviewed that patch, and there's only one chunk that could 
> possibly have a functional effect. The patch below undoes it - does that 
> fix the crashes you are seeing? [If you have lockdep enabled then this 
> patch will cause a lockdep false positive - ignore that one for now, it 
> shouldnt impact the crash scenario itself.]
> 

started the tests with this patch now. will report back in couple of
hours... earlier if it crashes again :), which i doubt.

Thanks & regards,

chandra
> 	Ingo
> 
> --------------------->
> Subject: revert slab.c locking change
> From: Ingo Molnar <mingo@elte.hu>
> 
> Chandra Seetharaman reported SLAB crashes caused by the slab.c
> lock annotation patch. There is only one chunk of that patch
> that has a material effect on the slab logic - this patch
> undoes that chunk.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  mm/slab.c |    9 ---------
>  1 file changed, 9 deletions(-)
> 
> Index: linux/mm/slab.c
> ===================================================================
> --- linux.orig/mm/slab.c
> +++ linux/mm/slab.c
> @@ -3100,16 +3100,7 @@ static void free_block(struct kmem_cache
>  		if (slabp->inuse == 0) {
>  			if (l3->free_objects > l3->free_limit) {
>  				l3->free_objects -= cachep->num;
> -				/*
> -				 * It is safe to drop the lock. The slab is
> -				 * no longer linked to the cache. cachep
> -				 * cannot disappear - we are using it and
> -				 * all destruction of caches must be
> -				 * serialized properly by the user.
> -				 */
> -				spin_unlock(&l3->list_lock);
>  				slab_destroy(cachep, slabp);
> -				spin_lock(&l3->list_lock);
>  			} else {
>  				list_add(&slabp->list, &l3->slabs_free);
>  			}
-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------

Re: Random panics seen in 2.6.18-rc1

[Chandra Seetharaman]

On Thu, 2006-07-13 at 06:51 -0700, Chandra Seetharaman wrote:

Tests are running for more than 2 hours now. So, this patch fixed the
panics i was seeing.

Thanks Ingo.

chandra
> On Thu, 2006-07-13 at 09:12 +0200, Ingo Molnar wrote:
> > * Chandra Seetharaman <sekharan@us.ibm.com> wrote:
> > 
> > > By adding one patch at a time to 2.6.17's mm/slab.c, I found that the
> > > following patch is the cause of the panic.
> > > --------------
> > > [PATCH] lockdep: annotate SLAB code
> > 
> > great debugging!
> 
> Thanks. 
> > 
> > I have reviewed that patch, and there's only one chunk that could 
> > possibly have a functional effect. The patch below undoes it - does that 
> > fix the crashes you are seeing? [If you have lockdep enabled then this 
> > patch will cause a lockdep false positive - ignore that one for now, it 
> > shouldnt impact the crash scenario itself.]
> > 
> 
> started the tests with this patch now. will report back in couple of
> hours... earlier if it crashes again :), which i doubt.
> 
> Thanks & regards,
> 
> chandra
> > 	Ingo
> > 
> > --------------------->
> > Subject: revert slab.c locking change
> > From: Ingo Molnar <mingo@elte.hu>
> > 
> > Chandra Seetharaman reported SLAB crashes caused by the slab.c
> > lock annotation patch. There is only one chunk of that patch
> > that has a material effect on the slab logic - this patch
> > undoes that chunk.
> > 
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > ---
> >  mm/slab.c |    9 ---------
> >  1 file changed, 9 deletions(-)
> > 
> > Index: linux/mm/slab.c
> > ===================================================================
> > --- linux.orig/mm/slab.c
> > +++ linux/mm/slab.c
> > @@ -3100,16 +3100,7 @@ static void free_block(struct kmem_cache
> >  		if (slabp->inuse == 0) {
> >  			if (l3->free_objects > l3->free_limit) {
> >  				l3->free_objects -= cachep->num;
> > -				/*
> > -				 * It is safe to drop the lock. The slab is
> > -				 * no longer linked to the cache. cachep
> > -				 * cannot disappear - we are using it and
> > -				 * all destruction of caches must be
> > -				 * serialized properly by the user.
> > -				 */
> > -				spin_unlock(&l3->list_lock);
> >  				slab_destroy(cachep, slabp);
> > -				spin_lock(&l3->list_lock);
> >  			} else {
> >  				list_add(&slabp->list, &l3->slabs_free);
> >  			}
-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------