All of lore.kernel.org
 help / color / mirror / Atom feed
* PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-06-11  6:23 Török Edwin
  2015-06-11 15:16 ` Brian Foster
  0 siblings, 1 reply; 38+ messages in thread
From: Török Edwin @ 2015-06-11  6:23 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

[1.] XFS on ARM corruption 'Structure needs cleaning'
[2.] Full description of the problem/report:

I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.

Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
and dmesg shows a corruption error [6.].
xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
I still get the 'Structure needs cleaning' error.

Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.

[3.] Keywords: filesystems, XFS corruption, ARM
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
[4.2.] Kernel .config file:
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.14.3 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_ARM_DMA_USE_IOMMU=y
CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_NEED_MACH_IO_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_GENERIC_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_EXPERT=y
# CONFIG_UID16 is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_CMDLINE_PARSER is not set

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

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_FREEZER is not set

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_MULTIPLATFORM is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
CONFIG_ARCH_STINGER=y
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM_NODT is not set
# CONFIG_ARCH_SHMOBILE_LEGACY is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set
# CONFIG_PLAT_SPEAR is not set

#
# HGST Stinger options
#
CONFIG_ARCH_STINGER_1x_SOC=y

#
# Stinger board type
#
CONFIG_MACH_PANTHEON=y
CONFIG_MACH_HORNET=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_KUSER_HELPERS=y
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_458693 is not set
# CONFIG_ARM_ERRATA_460075 is not set
# CONFIG_PL310_ERRATA_588369 is not set
# CONFIG_ARM_ERRATA_720789 is not set
# CONFIG_PL310_ERRATA_727915 is not set
# CONFIG_ARM_ERRATA_743622 is not set
# CONFIG_ARM_ERRATA_751472 is not set
# CONFIG_PL310_ERRATA_753970 is not set
CONFIG_ARM_ERRATA_754322=y
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
# CONFIG_ARM_ERRATA_773022 is not set

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
# CONFIG_HAVE_ARM_ARCH_TIMER is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ_FIXED=0
CONFIG_HZ_100=y
# CONFIG_HZ_200 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_500 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
# CONFIG_SCHED_HRTICK is not set
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_NO_BOOTMEM=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_CMA=y
CONFIG_CMA_DEBUG=y
# CONFIG_ZBUD is not set
# CONFIG_ZSMALLOC is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y

#
# Boot options
#
# CONFIG_USE_OF is not set
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
CONFIG_CMDLINE="console=ttyAMA0,115200n8"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
CONFIG_CRASH_DUMP=y
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Idle
#
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y

#
# Power management options
#
# CONFIG_SUSPEND is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ARM_CPU_SUSPEND is not set
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_NET_IP_TUNNEL=y
# CONFIG_IP_MROUTE is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# 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=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_VTI is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
CONFIG_VLAN_8021Q=y
# CONFIG_VLAN_8021Q_GVRP is not set
# CONFIG_VLAN_8021Q_MVRP is not set
# CONFIG_DECNET is not set
# 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_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_NET_MPLS_GSO is not set
# CONFIG_HSR is not set
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
CONFIG_DEBUG_DRIVER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
# CONFIG_DMA_SHARED_BUFFER is not set
CONFIG_DMA_CMA=y

#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=270
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
CONFIG_CMA_AREAS=7

#
# Bus devices
#
# CONFIG_ARM_CCI is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_STINGER_FIC=y
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_NULL_BLK is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=40960
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_93CX6 is not set

#
# Texas Instruments shared transport line discipline
#

#
# Altera FPGA firmware download module
#

#
# Intel MIC Host Driver
#

#
# Intel MIC Card Driver
#

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
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 is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
CONFIG_SCSI_HGST_STINGER=y
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=y
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NLMON is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_ARC=y
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8851_MLL is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
# CONFIG_SH_ETH is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_SMC91X is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_VIA=y
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
# CONFIG_PHYLIB is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
CONFIG_STINGER_NET=y
CONFIG_STINGER_NET_DEV=y
CONFIG_STINGER_NET_NIC=y
CONFIG_STINGER_NET_TOE=y
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV 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_LKKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_AMBAKMI is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_AMBA_PL010=y
CONFIG_SERIAL_AMBA_PL010_CONSOLE=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_SERIAL_SH_SCI is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_VEXPRESS_CONFIG is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
# CONFIG_FB is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_XINMO is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# PHY Subsystem
#
# CONFIG_GENERIC_PHY is not set
# CONFIG_PHY_EXYNOS_MIPI_VIDEO is not set
# CONFIG_POWERCAP is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4_FS=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
CONFIG_FSCACHE=y
CONFIG_FSCACHE_STATS=y
CONFIG_FSCACHE_HISTOGRAM=y
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
# CONFIG_CACHEFILES is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# 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_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
CONFIG_NFS_V4_1=y
# CONFIG_NFS_V4_2 is not set
CONFIG_PNFS_FILE_LAYOUT=y
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
# CONFIG_NFS_V4_1_MIGRATION is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_FSCACHE is not set
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
# CONFIG_NFSD_FAULT_INJECTION is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_SUNRPC_BACKCHANNEL=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_NLS is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#

#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set

#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_DEBUG_KERNEL=y

#
# Memory Debugging
#
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_HIGHMEM=y
# CONFIG_DEBUG_SHIRQ is not set

#
# Debug Lockups and Hangs
#
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=5
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
# 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_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set

#
# RCU Debugging
#
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set

#
# Runtime Testing
#
# CONFIG_LKDTM is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_PERCPU_TEST is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_TEST_MODULE is not set
# CONFIG_TEST_USER_COPY is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_ARM_PTDUMP is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_NONE=y
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
# CONFIG_DEBUG_LL_UART_8250 is not set
# CONFIG_DEBUG_LL_UART_PL01X is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_DEBUG_UART_PL01X is not set
# CONFIG_DEBUG_UART_8250 is not set
CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set
# CONFIG_DEBUG_SET_MODULE_RONX is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_PERSISTENT_KEYRINGS is not set
# CONFIG_BIG_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=m
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRCT10DIF is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_OID_REGISTRY=y
# CONFIG_VIRTUALIZATION is not set

[5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM

[6.] dmesg stacktrace

[4627578.440000] XFS (sda4): Mounting Filesystem
[4627578.510000] XFS (sda4): Ending clean mount
[4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
[4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
[4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
[4627621.500000] XFS (sda4): Internal error xfs_dir3_data_read_verify at line 274 of file fs/xfs/xfs_dir2_data.c.  Caller 0xc01c1528
[4627621.510000] CPU: 0 PID: 37 Comm: kworker/0:1H Not tainted 3.14.3-00088-g7651c68 #24
[4627621.510000] Workqueue: xfslogd xfs_buf_iodone_work
[4627621.510000] [<c0013948>] (unwind_backtrace) from [<c0011058>] (show_stack+0x10/0x14)
[4627621.510000] [<c0011058>] (show_stack) from [<c01c3dc4>] (xfs_corruption_error+0x54/0x70)
[4627621.510000] [<c01c3dc4>] (xfs_corruption_error) from [<c01f7854>] (xfs_dir3_data_read_verify+0x60/0xd0)
[4627621.510000] [<c01f7854>] (xfs_dir3_data_read_verify) from [<c01c1528>] (xfs_buf_iodone_work+0x7c/0x94)
[4627621.510000] [<c01c1528>] (xfs_buf_iodone_work) from [<c00309f0>] (process_one_work+0xf4/0x32c)
[4627621.510000] [<c00309f0>] (process_one_work) from [<c0030fb4>] (worker_thread+0x10c/0x388)
[4627621.510000] [<c0030fb4>] (worker_thread) from [<c0035e10>] (kthread+0xbc/0xd8)
[4627621.510000] [<c0035e10>] (kthread) from [<c000e8f8>] (ret_from_fork+0x14/0x3c)
[4627621.510000] XFS (sda4): Corruption detected. Unmount and run xfs_repair
[4627621.520000] XFS (sda4): metadata I/O error: block 0x6e804200 ("xfs_trans_read_buf_map") error 117 numblks 8

[7.] Testcase:

$ curl -O http://vol-public.s3.indian.skylable.com:8008/armel/testcase/libsx2_1.1-1_armel.deb
$ curl -O http://vol-public.s3.indian.skylable.com:8008/armel/testcase/sx_1.1-1_armel.deb
$ sudo dpkg -i libsx2_*.deb sx_*.deb
$ sudo umount /export/dfs
$ sudo mkfs.xfs -f /dev/sda4
$ sudo mount /dev/sda4 /export/dfs
$ sudo mkdir /export/dfs/a
$ sudo sxadm node --new --batch /export/dfs/a/b
$ sudo ls /export/dfs/a/b
ls: reading directory /export/dfs/a/b: Structure needs cleaning
$ dmesg
$ sudo umount /export/dfs
$ sudo xfs_repair /dev/sda4
$ sudo mount /dev/sda4 /export/dfs
$ sudo ls /export/dfs/a/b
ls: reading directory /export/dfs/a/b: Structure needs cleaning

'sxadm node --new' uses SQLite3 to create a set of new databases and reproduces the problem reliably.
However I was not able to reproduce this by just using the command-line sqlite tools.

The source code of sxadm can be found here if you want to build manually instead of using a package:
http://gitweb.skylable.com/gitweb/?p=sx.git;a=summary

[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
 
Gnu C                  
binutils               
util-linux             2.20.1
mount                  support
module-init-tools      16
e2fsprogs              1.42.9
xfsprogs               3.1.9
Linux C Library        2.17
Dynamic linker (ldd)   2.17
Procps                 3.3.9
Net-tools              1.60
Kbd                    
Sh-utils               8.21
Modules Loaded 

[8.2.] Processor information (from /proc/cpuinfo):
processor       : 0
model name      : ARMv7 Processor rev 0 (v7l)
Features        : swp half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 0

Hardware        : hornet
Revision        : 0000
Serial          : 0000000000000000

[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
14872000-14872fff : sn_dev
14a00000-14a3ffff : sn_dev
14050000-14050fff : uart
  14050000-14050fff : uart-pl011
30000000-9fffffff : System RAM
  30008000-304f616f : Kernel code
  30518000-305ae327 : Kernel data

[8.6.] /proc/scsi/scsi:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: HGST     Model: HUS724040ALS640  Rev: aH1F
  Type:   Direct-Access                    ANSI  SCSI revision: 06

[8.7.] /proc/fs/xfs/stat:
extent_alloc 199 5043 79 570
abt 0 0 0 0
blk_map 16325 7059 666 192 363 24055 0
bmbt 0 0 0 0
dir 461 594 476 18
trans 9 4656 252
ig 0 215 0 383 0 383 954
log 30 546 0 74041 11
push_ail 4971 0 1821 59 0 270 0 250 0 3
xstrat 184 0
rw 8005 8827
attr 412 0 0 0
icluster 22 17 250
vnodes 4294966698 0 0 0 598 598 598 0
buf 6693 101 6661 5 0 32 0 45 15
abtb2 287 399 11 10 0 0 0 0 0 0 0 0 0 0 24
abtc2 557 766 279 278 0 0 0 0 0 0 0 0 0 0 560
bmbt2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ibt2 1896 3700 7 5 0 0 0 0 0 0 0 0 0 0 2
qm 0 0 0 0 0 0 0 0
xpc 20508672 20922056 263794352
debug 0

Best regards,
--Edwin


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11  6:23 PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Török Edwin
@ 2015-06-11 15:16 ` Brian Foster
  2015-06-11 15:28   ` Török Edwin
  0 siblings, 1 reply; 38+ messages in thread
From: Brian Foster @ 2015-06-11 15:16 UTC (permalink / raw)
  To: Török Edwin; +Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
> [1.] XFS on ARM corruption 'Structure needs cleaning'
> [2.] Full description of the problem/report:
> 
> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
> 
> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
> and dmesg shows a corruption error [6.].
> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
> I still get the 'Structure needs cleaning' error.
> 
> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
> 
> [3.] Keywords: filesystems, XFS corruption, ARM
> [4.] Kernel information
> [4.1.] Kernel version (from /proc/version):
> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
> 
...
> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
> 
> [6.] dmesg stacktrace
> 
> [4627578.440000] XFS (sda4): Mounting Filesystem
> [4627578.510000] XFS (sda4): Ending clean mount
> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........

Just a data point... the magic number here looks like a superblock magic
(XFSB) rather than one of the directory magic numbers. I'm wondering if
a buffer disk address has gone bad somehow or another.

Does this happen to be a large block device? I don't see any partition
or xfs_info data below. If so, it would be interesting to see if this
reproduces on a smaller device. It does appear that the large block
device option is enabled in the kernel config above, however, so maybe
that's unrelated.

Brian

> [4627621.500000] XFS (sda4): Internal error xfs_dir3_data_read_verify at line 274 of file fs/xfs/xfs_dir2_data.c.  Caller 0xc01c1528
> [4627621.510000] CPU: 0 PID: 37 Comm: kworker/0:1H Not tainted 3.14.3-00088-g7651c68 #24
> [4627621.510000] Workqueue: xfslogd xfs_buf_iodone_work
> [4627621.510000] [<c0013948>] (unwind_backtrace) from [<c0011058>] (show_stack+0x10/0x14)
> [4627621.510000] [<c0011058>] (show_stack) from [<c01c3dc4>] (xfs_corruption_error+0x54/0x70)
> [4627621.510000] [<c01c3dc4>] (xfs_corruption_error) from [<c01f7854>] (xfs_dir3_data_read_verify+0x60/0xd0)
> [4627621.510000] [<c01f7854>] (xfs_dir3_data_read_verify) from [<c01c1528>] (xfs_buf_iodone_work+0x7c/0x94)
> [4627621.510000] [<c01c1528>] (xfs_buf_iodone_work) from [<c00309f0>] (process_one_work+0xf4/0x32c)
> [4627621.510000] [<c00309f0>] (process_one_work) from [<c0030fb4>] (worker_thread+0x10c/0x388)
> [4627621.510000] [<c0030fb4>] (worker_thread) from [<c0035e10>] (kthread+0xbc/0xd8)
> [4627621.510000] [<c0035e10>] (kthread) from [<c000e8f8>] (ret_from_fork+0x14/0x3c)
> [4627621.510000] XFS (sda4): Corruption detected. Unmount and run xfs_repair
> [4627621.520000] XFS (sda4): metadata I/O error: block 0x6e804200 ("xfs_trans_read_buf_map") error 117 numblks 8
> 
> [7.] Testcase:
> 
> $ curl -O http://vol-public.s3.indian.skylable.com:8008/armel/testcase/libsx2_1.1-1_armel.deb
> $ curl -O http://vol-public.s3.indian.skylable.com:8008/armel/testcase/sx_1.1-1_armel.deb
> $ sudo dpkg -i libsx2_*.deb sx_*.deb
> $ sudo umount /export/dfs
> $ sudo mkfs.xfs -f /dev/sda4
> $ sudo mount /dev/sda4 /export/dfs
> $ sudo mkdir /export/dfs/a
> $ sudo sxadm node --new --batch /export/dfs/a/b
> $ sudo ls /export/dfs/a/b
> ls: reading directory /export/dfs/a/b: Structure needs cleaning
> $ dmesg
> $ sudo umount /export/dfs
> $ sudo xfs_repair /dev/sda4
> $ sudo mount /dev/sda4 /export/dfs
> $ sudo ls /export/dfs/a/b
> ls: reading directory /export/dfs/a/b: Structure needs cleaning
> 
> 'sxadm node --new' uses SQLite3 to create a set of new databases and reproduces the problem reliably.
> However I was not able to reproduce this by just using the command-line sqlite tools.
> 
> The source code of sxadm can be found here if you want to build manually instead of using a package:
> http://gitweb.skylable.com/gitweb/?p=sx.git;a=summary
> 
> [8.] Environment
> [8.1.] Software (add the output of the ver_linux script here)
> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
>  
> Gnu C                  
> binutils               
> util-linux             2.20.1
> mount                  support
> module-init-tools      16
> e2fsprogs              1.42.9
> xfsprogs               3.1.9
> Linux C Library        2.17
> Dynamic linker (ldd)   2.17
> Procps                 3.3.9
> Net-tools              1.60
> Kbd                    
> Sh-utils               8.21
> Modules Loaded 
> 
> [8.2.] Processor information (from /proc/cpuinfo):
> processor       : 0
> model name      : ARMv7 Processor rev 0 (v7l)
> Features        : swp half thumb fastmult edsp tls 
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x4
> CPU part        : 0xc09
> CPU revision    : 0
> 
> Hardware        : hornet
> Revision        : 0000
> Serial          : 0000000000000000
> 
> [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
> 14872000-14872fff : sn_dev
> 14a00000-14a3ffff : sn_dev
> 14050000-14050fff : uart
>   14050000-14050fff : uart-pl011
> 30000000-9fffffff : System RAM
>   30008000-304f616f : Kernel code
>   30518000-305ae327 : Kernel data
> 
> [8.6.] /proc/scsi/scsi:
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>   Vendor: HGST     Model: HUS724040ALS640  Rev: aH1F
>   Type:   Direct-Access                    ANSI  SCSI revision: 06
> 
> [8.7.] /proc/fs/xfs/stat:
> extent_alloc 199 5043 79 570
> abt 0 0 0 0
> blk_map 16325 7059 666 192 363 24055 0
> bmbt 0 0 0 0
> dir 461 594 476 18
> trans 9 4656 252
> ig 0 215 0 383 0 383 954
> log 30 546 0 74041 11
> push_ail 4971 0 1821 59 0 270 0 250 0 3
> xstrat 184 0
> rw 8005 8827
> attr 412 0 0 0
> icluster 22 17 250
> vnodes 4294966698 0 0 0 598 598 598 0
> buf 6693 101 6661 5 0 32 0 45 15
> abtb2 287 399 11 10 0 0 0 0 0 0 0 0 0 0 24
> abtc2 557 766 279 278 0 0 0 0 0 0 0 0 0 0 560
> bmbt2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> ibt2 1896 3700 7 5 0 0 0 0 0 0 0 0 0 0 2
> qm 0 0 0 0 0 0 0 0
> xpc 20508672 20922056 263794352
> debug 0
> 
> Best regards,
> --Edwin
> 
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 15:16 ` Brian Foster
@ 2015-06-11 15:28   ` Török Edwin
  2015-06-11 15:51     ` Eric Sandeen
  0 siblings, 1 reply; 38+ messages in thread
From: Török Edwin @ 2015-06-11 15:28 UTC (permalink / raw)
  To: Brian Foster; +Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 06/11/2015 06:16 PM, Brian Foster wrote:
> On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
>> [1.] XFS on ARM corruption 'Structure needs cleaning'
>> [2.] Full description of the problem/report:
>>
>> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
>>
>> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
>> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
>> and dmesg shows a corruption error [6.].
>> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
>> I still get the 'Structure needs cleaning' error.
>>
>> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
>> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
>>
>> [3.] Keywords: filesystems, XFS corruption, ARM
>> [4.] Kernel information
>> [4.1.] Kernel version (from /proc/version):
>> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
>>
> ...
>> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
>>
>> [6.] dmesg stacktrace
>>
>> [4627578.440000] XFS (sda4): Mounting Filesystem
>> [4627578.510000] XFS (sda4): Ending clean mount
>> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
>> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
>> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
> 
> Just a data point... the magic number here looks like a superblock magic
> (XFSB) rather than one of the directory magic numbers. I'm wondering if
> a buffer disk address has gone bad somehow or another.
> 
> Does this happen to be a large block device? I don't see any partition
> or xfs_info data below. If so, it would be interesting to see if this
> reproduces on a smaller device. It does appear that the large block
> device option is enabled in the kernel config above, however, so maybe
> that's unrelated.

This is mkfs.xfs /dev/sda4:
meta-data=/dev/sda4              isize=256    agcount=4, agsize=231737408 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=926949632, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=452612, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

But it also reproduces with this small loopback file:
meta-data=/tmp/xfs.test          isize=256    agcount=2, agsize=5120 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=10240, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

You can have a look at xfs.test here: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs.test.gz

If I loopback mount that on an x86-64 box it doesn't show the corruption message though ...

Best regards,
--Edwin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 15:28   ` Török Edwin
@ 2015-06-11 15:51     ` Eric Sandeen
  2015-06-11 15:58       ` Eric Sandeen
  0 siblings, 1 reply; 38+ messages in thread
From: Eric Sandeen @ 2015-06-11 15:51 UTC (permalink / raw)
  To: Török Edwin, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 6/11/15 10:28 AM, Török Edwin wrote:
> On 06/11/2015 06:16 PM, Brian Foster wrote:
>> On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
>>> [1.] XFS on ARM corruption 'Structure needs cleaning'
>>> [2.] Full description of the problem/report:
>>>
>>> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
>>>
>>> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
>>> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
>>> and dmesg shows a corruption error [6.].
>>> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
>>> I still get the 'Structure needs cleaning' error.
>>>
>>> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
>>> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
>>>
>>> [3.] Keywords: filesystems, XFS corruption, ARM
>>> [4.] Kernel information
>>> [4.1.] Kernel version (from /proc/version):
>>> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
>>>
>> ...
>>> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
>>>
>>> [6.] dmesg stacktrace
>>>
>>> [4627578.440000] XFS (sda4): Mounting Filesystem
>>> [4627578.510000] XFS (sda4): Ending clean mount
>>> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
>>> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
>>> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
>>
>> Just a data point... the magic number here looks like a superblock magic
>> (XFSB) rather than one of the directory magic numbers. I'm wondering if
>> a buffer disk address has gone bad somehow or another.
>>
>> Does this happen to be a large block device? I don't see any partition
>> or xfs_info data below. If so, it would be interesting to see if this
>> reproduces on a smaller device. It does appear that the large block
>> device option is enabled in the kernel config above, however, so maybe
>> that's unrelated.
> 
> This is mkfs.xfs /dev/sda4:
> meta-data=/dev/sda4              isize=256    agcount=4, agsize=231737408 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=4096   blocks=926949632, imaxpct=5
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=452612, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> But it also reproduces with this small loopback file:
> meta-data=/tmp/xfs.test          isize=256    agcount=2, agsize=5120 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=4096   blocks=10240, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0

ok so not a block number overflow issue, thanks.

> You can have a look at xfs.test here: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs.test.gz
> 
> If I loopback mount that on an x86-64 box it doesn't show the corruption message though ...

FWIW, this is the 2nd report we've had of something similar, both on Armv7, both ok on x86_64.

I'll take a look at your xfs.test; that's presumably copied after it reported the error, and you unmounted it before uploading, correct?  And it was mkfs'd on armv7, never mounted or manipulated in any way on x86_64?

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 15:51     ` Eric Sandeen
@ 2015-06-11 15:58       ` Eric Sandeen
  2015-06-11 16:32         ` Török Edwin
  0 siblings, 1 reply; 38+ messages in thread
From: Eric Sandeen @ 2015-06-11 15:58 UTC (permalink / raw)
  To: Török Edwin, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 6/11/15 10:51 AM, Eric Sandeen wrote:
> On 6/11/15 10:28 AM, Török Edwin wrote:
>> On 06/11/2015 06:16 PM, Brian Foster wrote:
>>> On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
>>>> [1.] XFS on ARM corruption 'Structure needs cleaning'
>>>> [2.] Full description of the problem/report:
>>>>
>>>> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
>>>>
>>>> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
>>>> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
>>>> and dmesg shows a corruption error [6.].
>>>> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
>>>> I still get the 'Structure needs cleaning' error.
>>>>
>>>> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
>>>> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
>>>>
>>>> [3.] Keywords: filesystems, XFS corruption, ARM
>>>> [4.] Kernel information
>>>> [4.1.] Kernel version (from /proc/version):
>>>> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
>>>>
>>> ...
>>>> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
>>>>
>>>> [6.] dmesg stacktrace
>>>>
>>>> [4627578.440000] XFS (sda4): Mounting Filesystem
>>>> [4627578.510000] XFS (sda4): Ending clean mount
>>>> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
>>>> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>>> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
>>>> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
>>>
>>> Just a data point... the magic number here looks like a superblock magic
>>> (XFSB) rather than one of the directory magic numbers. I'm wondering if
>>> a buffer disk address has gone bad somehow or another.
>>>
>>> Does this happen to be a large block device? I don't see any partition
>>> or xfs_info data below. If so, it would be interesting to see if this
>>> reproduces on a smaller device. It does appear that the large block
>>> device option is enabled in the kernel config above, however, so maybe
>>> that's unrelated.
>>
>> This is mkfs.xfs /dev/sda4:
>> meta-data=/dev/sda4              isize=256    agcount=4, agsize=231737408 blks
>>          =                       sectsz=512   attr=2, projid32bit=0
>> data     =                       bsize=4096   blocks=926949632, imaxpct=5
>>          =                       sunit=0      swidth=0 blks
>> naming   =version 2              bsize=4096   ascii-ci=0
>> log      =internal log           bsize=4096   blocks=452612, version=2
>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>>
>> But it also reproduces with this small loopback file:
>> meta-data=/tmp/xfs.test          isize=256    agcount=2, agsize=5120 blks
>>          =                       sectsz=512   attr=2, projid32bit=0
>> data     =                       bsize=4096   blocks=10240, imaxpct=25
>>          =                       sunit=0      swidth=0 blks
>> naming   =version 2              bsize=4096   ascii-ci=0
>> log      =internal log           bsize=4096   blocks=1200, version=2
>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
>> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> ok so not a block number overflow issue, thanks.
> 
>> You can have a look at xfs.test here: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs.test.gz
>>
>> If I loopback mount that on an x86-64 box it doesn't show the corruption message though ...
> 
> FWIW, this is the 2nd report we've had of something similar, both on Armv7, both ok on x86_64.
> 
> I'll take a look at your xfs.test; that's presumably copied after it reported the error, and you unmounted it before uploading, correct?  And it was mkfs'd on armv7, never mounted or manipulated in any way on x86_64?

Oh, and what were the kernel messages when you produced the corruption with xfs.txt?

thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 15:58       ` Eric Sandeen
@ 2015-06-11 16:32         ` Török Edwin
  2015-06-11 17:10           ` Eric Sandeen
                             ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Török Edwin @ 2015-06-11 16:32 UTC (permalink / raw)
  To: Eric Sandeen, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 06/11/2015 06:58 PM, Eric Sandeen wrote:
> On 6/11/15 10:51 AM, Eric Sandeen wrote:
>> On 6/11/15 10:28 AM, Török Edwin wrote:
>>> On 06/11/2015 06:16 PM, Brian Foster wrote:
>>>> On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
>>>>> [1.] XFS on ARM corruption 'Structure needs cleaning'
>>>>> [2.] Full description of the problem/report:
>>>>>
>>>>> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
>>>>>
>>>>> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
>>>>> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
>>>>> and dmesg shows a corruption error [6.].
>>>>> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
>>>>> I still get the 'Structure needs cleaning' error.
>>>>>
>>>>> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
>>>>> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
>>>>>
>>>>> [3.] Keywords: filesystems, XFS corruption, ARM
>>>>> [4.] Kernel information
>>>>> [4.1.] Kernel version (from /proc/version):
>>>>> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
>>>>>
>>>> ...
>>>>> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
>>>>>
>>>>> [6.] dmesg stacktrace
>>>>>
>>>>> [4627578.440000] XFS (sda4): Mounting Filesystem
>>>>> [4627578.510000] XFS (sda4): Ending clean mount
>>>>> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
>>>>> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>>>> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
>>>>> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
>>>>
>>>> Just a data point... the magic number here looks like a superblock magic
>>>> (XFSB) rather than one of the directory magic numbers. I'm wondering if
>>>> a buffer disk address has gone bad somehow or another.
>>>>
>>>> Does this happen to be a large block device? I don't see any partition
>>>> or xfs_info data below. If so, it would be interesting to see if this
>>>> reproduces on a smaller device. It does appear that the large block
>>>> device option is enabled in the kernel config above, however, so maybe
>>>> that's unrelated.
>>>
>>> This is mkfs.xfs /dev/sda4:
>>> meta-data=/dev/sda4              isize=256    agcount=4, agsize=231737408 blks
>>>          =                       sectsz=512   attr=2, projid32bit=0
>>> data     =                       bsize=4096   blocks=926949632, imaxpct=5
>>>          =                       sunit=0      swidth=0 blks
>>> naming   =version 2              bsize=4096   ascii-ci=0
>>> log      =internal log           bsize=4096   blocks=452612, version=2
>>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
>>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>>>
>>> But it also reproduces with this small loopback file:
>>> meta-data=/tmp/xfs.test          isize=256    agcount=2, agsize=5120 blks
>>>          =                       sectsz=512   attr=2, projid32bit=0
>>> data     =                       bsize=4096   blocks=10240, imaxpct=25
>>>          =                       sunit=0      swidth=0 blks
>>> naming   =version 2              bsize=4096   ascii-ci=0
>>> log      =internal log           bsize=4096   blocks=1200, version=2
>>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
>>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>>
>> ok so not a block number overflow issue, thanks.
>>
>>> You can have a look at xfs.test here: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs.test.gz
>>>
>>> If I loopback mount that on an x86-64 box it doesn't show the corruption message though ...
>>
>> FWIW, this is the 2nd report we've had of something similar, both on Armv7, both ok on x86_64.
>>
>> I'll take a look at your xfs.test; that's presumably copied after it reported the error, and you unmounted it before uploading, correct?  And it was mkfs'd on armv7, never mounted or manipulated in any way on x86_64?

Thanks, yes it was mkfs.xfs on ARMv7 and unmounted.

> 
> Oh, and what were the kernel messages when you produced the corruption with xfs.txt?

Takes only a couple of minutes to reproduce the issue so I've prepared a fresh set of xfs2.test and corresponding kernel messages to make sure its all consistent.
Freshly created XFS by mkfs.xfs: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.orig.gz
The corrupted XFS: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.corrupted.gz

All commands below were run on armv7, and unmounted, the files from /tmp copied over to x86-64, gzipped and uploaded, they were never mounted on x86-64:

# dd if=/dev/zero of=/tmp/xfs2.test bs=1M count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 0.419997 s, 99.9 MB/s
# mkfs.xfs /tmp/xfs2.test
meta-data=/tmp/xfs2.test         isize=256    agcount=2, agsize=5120 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=10240, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# cp /tmp/xfs2.test /tmp/xfs2.test.orig
# umount /export/dfs
# mount -o loop -t xfs /tmp/xfs2.test /export/dfs
# mkdir /export/dfs/a
# sxadm node --new --batch /export/dfs/a/b
# ls /export/dfs/a/b
ls: reading directory /export/dfs/a/b: Structure needs cleaning
# umount /export/dfs
# cp /tmp/xfs2.test /tmp/xfs2.test.corrupted
# dmesg >/tmp/dmesg
# exit

the latest corruption message from dmesg:
[4744604.870000] XFS (loop0): Mounting Filesystem
[4744604.900000] XFS (loop0): Ending clean mount
[4745016.610000] dc61e000: 58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00  XFSB..........(.
[4745016.620000] dc61e010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[4745016.630000] dc61e020: 64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9  d#..2.L .n.6..T.
[4745016.640000] dc61e030: 00 00 00 00 00 00 20 04 00 00 00 00 00 00 00 80  ...... .........
[4745016.640000] XFS (loop0): Internal error xfs_dir3_data_read_verify at line 274 of file fs/xfs/xfs_dir2_data.c.  Caller 0xc01c1528
[4745016.650000] CPU: 0 PID: 37 Comm: kworker/0:1H Not tainted 3.14.3-00088-g7651c68 #24
[4745016.650000] Workqueue: xfslogd xfs_buf_iodone_work
[4745016.650000] [<c0013948>] (unwind_backtrace) from [<c0011058>] (show_stack+0x10/0x14)
[4745016.650000] [<c0011058>] (show_stack) from [<c01c3dc4>] (xfs_corruption_error+0x54/0x70)
[4745016.650000] [<c01c3dc4>] (xfs_corruption_error) from [<c01f7854>] (xfs_dir3_data_read_verify+0x60/0xd0)
[4745016.650000] [<c01f7854>] (xfs_dir3_data_read_verify) from [<c01c1528>] (xfs_buf_iodone_work+0x7c/0x94)
[4745016.650000] [<c01c1528>] (xfs_buf_iodone_work) from [<c00309f0>] (process_one_work+0xf4/0x32c)
[4745016.650000] [<c00309f0>] (process_one_work) from [<c0030fb4>] (worker_thread+0x10c/0x388)
[4745016.650000] [<c0030fb4>] (worker_thread) from [<c0035e10>] (kthread+0xbc/0xd8)
[4745016.650000] [<c0035e10>] (kthread) from [<c000e8f8>] (ret_from_fork+0x14/0x3c)
[4745016.650000] XFS (loop0): Corruption detected. Unmount and run xfs_repair
[4745016.650000] XFS (loop0): metadata I/O error: block 0xa000 ("xfs_trans_read_buf_map") error 117 numblks 8

Best regards,
--Edwin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 16:32         ` Török Edwin
@ 2015-06-11 17:10           ` Eric Sandeen
  2015-06-11 17:13             ` Török Edwin
  2015-06-11 20:07           ` Eric Sandeen
  2015-06-12 12:21           ` Brian Foster
  2 siblings, 1 reply; 38+ messages in thread
From: Eric Sandeen @ 2015-06-11 17:10 UTC (permalink / raw)
  To: Török Edwin, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 6/11/15 11:32 AM, Török Edwin wrote:
> # cp /tmp/xfs2.test /tmp/xfs2.test.orig
> # umount /export/dfs
> # mount -o loop -t xfs /tmp/xfs2.test /export/dfs
> # mkdir /export/dfs/a
> # sxadm node --new --batch /export/dfs/a/b
> # ls /export/dfs/a/b
> ls: reading directory /export/dfs/a/b: Structure needs cleaning
> # umount /export/dfs
> # cp /tmp/xfs2.test /tmp/xfs2.test.corrupted
> # dmesg >/tmp/dmesg
> # exit

Thanks.  Out of curiosity, if you now do:

# mount -o loop -t xfs /tmp/xfs2.test /export/dfs
# ls /export/dfs/a/b

do you still get the failure?  i.e. is it persistent on disk, still there after a remount, or is it perhaps only in memory?

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 17:10           ` Eric Sandeen
@ 2015-06-11 17:13             ` Török Edwin
  2015-06-11 17:16               ` Eric Sandeen
  0 siblings, 1 reply; 38+ messages in thread
From: Török Edwin @ 2015-06-11 17:13 UTC (permalink / raw)
  To: Eric Sandeen, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 06/11/2015 08:10 PM, Eric Sandeen wrote:
> On 6/11/15 11:32 AM, Török Edwin wrote:
>> # cp /tmp/xfs2.test /tmp/xfs2.test.orig
>> # umount /export/dfs
>> # mount -o loop -t xfs /tmp/xfs2.test /export/dfs
>> # mkdir /export/dfs/a
>> # sxadm node --new --batch /export/dfs/a/b
>> # ls /export/dfs/a/b
>> ls: reading directory /export/dfs/a/b: Structure needs cleaning
>> # umount /export/dfs
>> # cp /tmp/xfs2.test /tmp/xfs2.test.corrupted
>> # dmesg >/tmp/dmesg
>> # exit
> 
> Thanks.  Out of curiosity, if you now do:
> 
> # mount -o loop -t xfs /tmp/xfs2.test /export/dfs
> # ls /export/dfs/a/b

I get 'Structure needs cleaning' again.

> 
> do you still get the failure?  i.e. is it persistent on disk, still there after a remount,

It is persistent. I tried remounting, or unmount + xfs_repair + remount, or rm -rf /export/dfs/a, but once its corrupted it stays like that.

Best regards,
--Edwin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 17:13             ` Török Edwin
@ 2015-06-11 17:16               ` Eric Sandeen
  0 siblings, 0 replies; 38+ messages in thread
From: Eric Sandeen @ 2015-06-11 17:16 UTC (permalink / raw)
  To: Török Edwin, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 6/11/15 12:13 PM, Török Edwin wrote:
> It is persistent. I tried remounting, or unmount + xfs_repair +
> remount, or rm -rf /export/dfs/a, but once its corrupted it stays
> like that.

That narrows it down, thanks.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 16:32         ` Török Edwin
  2015-06-11 17:10           ` Eric Sandeen
@ 2015-06-11 20:07           ` Eric Sandeen
  2015-06-11 20:29             ` Eric Sandeen
  2015-06-11 22:53             ` Dave Chinner
  2015-06-12 12:21           ` Brian Foster
  2 siblings, 2 replies; 38+ messages in thread
From: Eric Sandeen @ 2015-06-11 20:07 UTC (permalink / raw)
  To: Török Edwin, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 6/11/15 11:32 AM, Török Edwin wrote:

> All commands below were run on armv7, and unmounted, the files from
> /tmp copied over to x86-64, gzipped and uploaded, they were never
> mounted on x86-64:
> 
> # dd if=/dev/zero of=/tmp/xfs2.test bs=1M count=40
> 40+0 records in
> 40+0 records out
> 41943040 bytes (42 MB) copied, 0.419997 s, 99.9 MB/s
> # mkfs.xfs /tmp/xfs2.test
> meta-data=/tmp/xfs2.test         isize=256    agcount=2, agsize=5120 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=4096   blocks=10240, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> # cp /tmp/xfs2.test /tmp/xfs2.test.orig
> # umount /export/dfs
> # mount -o loop -t xfs /tmp/xfs2.test /export/dfs
> # mkdir /export/dfs/a
> # sxadm node --new --batch /export/dfs/a/b
> # ls /export/dfs/a/b
> ls: reading directory /export/dfs/a/b: Structure needs cleaning

ok, so dir a/b/ is inode 150400

# ls -id mnt/a/b
150400 mnt/a/b

xfs_db> inode 150400
xfs_db> p
...
core.format = 2 (extents)
...
u.bmx[0-2] = [startoff,startblock,blockcount,extentflag] 0:[0,9420,1,0] 1:[1,9553,1,0] 2:[8388608,9489,1,0]

so those are the blocks it should be reading as directory data; somehow it's finding a superblock instead (?!)

None of those physical blocks are particularly interesting; 9420, 9553, 9489 - nothing that could/should be weirdly shifted or overflowed or bit-flipped to read block 0, AFAICT.

The hexdump below has superblock magic, and this filesystem has only 2 superblocks, at fs block 0 and fs block 8192.  Nothing really in common with the 3 directory blocks above.

> # umount /export/dfs
> # cp /tmp/xfs2.test /tmp/xfs2.test.corrupted
> # dmesg >/tmp/dmesg
> # exit
> 
> the latest corruption message from dmesg:
> [4744604.870000] XFS (loop0): Mounting Filesystem
> [4744604.900000] XFS (loop0): Ending clean mount
> [4745016.610000] dc61e000: 58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00  XFSB..........(.
> [4745016.620000] dc61e010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> [4745016.630000] dc61e020: 64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9  d#..2.L .n.6..T.
> [4745016.640000] dc61e030: 00 00 00 00 00 00 20 04 00 00 00 00 00 00 00 80  ...... .........
> [4745016.640000] XFS (loop0): Internal error xfs_dir3_data_read_verify at line 274 of file fs/xfs/xfs_dir2_data.c.  Caller 0xc01c1528
> [4745016.650000] CPU: 0 PID: 37 Comm: kworker/0:1H Not tainted 3.14.3-00088-g7651c68 #24
> [4745016.650000] Workqueue: xfslogd xfs_buf_iodone_work
> [4745016.650000] [<c0013948>] (unwind_backtrace) from [<c0011058>] (show_stack+0x10/0x14)
> [4745016.650000] [<c0011058>] (show_stack) from [<c01c3dc4>] (xfs_corruption_error+0x54/0x70)
> [4745016.650000] [<c01c3dc4>] (xfs_corruption_error) from [<c01f7854>] (xfs_dir3_data_read_verify+0x60/0xd0)
> [4745016.650000] [<c01f7854>] (xfs_dir3_data_read_verify) from [<c01c1528>] (xfs_buf_iodone_work+0x7c/0x94)
> [4745016.650000] [<c01c1528>] (xfs_buf_iodone_work) from [<c00309f0>] (process_one_work+0xf4/0x32c)
> [4745016.650000] [<c00309f0>] (process_one_work) from [<c0030fb4>] (worker_thread+0x10c/0x388)
> [4745016.650000] [<c0030fb4>] (worker_thread) from [<c0035e10>] (kthread+0xbc/0xd8)
> [4745016.650000] [<c0035e10>] (kthread) from [<c000e8f8>] (ret_from_fork+0x14/0x3c)
> [4745016.650000] XFS (loop0): Corruption detected. Unmount and run xfs_repair
> [4745016.650000] XFS (loop0): metadata I/O error: block 0xa000 ("xfs_trans_read_buf_map") error 117 numblks 8

ok, block 0xA000 (in sectors) is sector 40960...

xfs_db> daddr 40960
xfs_db> fsblock 
current fsblock is 8192
xfs_db> type text
xfs_db> p
000:  58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00  XFSB............
010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
020:  64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9  d...2.L..n.6..T.

...

Right, so it's reading the 2nd superblock in xfs_dir3_data_read_verify.  Huh?
(I could have imagined some weird scenario where we read block 0, but 8192?
Very strange).

Hm, I don't think this can be readahead, it'd not get to this verifier AFAICT.

Given that the image is enough to reproduce via just mount; ls - we should be
able to reproduce this, given the right hardware, and get to the bottom of it.

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 20:07           ` Eric Sandeen
@ 2015-06-11 20:29             ` Eric Sandeen
  2015-06-11 22:53             ` Dave Chinner
  1 sibling, 0 replies; 38+ messages in thread
From: Eric Sandeen @ 2015-06-11 20:29 UTC (permalink / raw)
  To: Török Edwin, Brian Foster
  Cc: Christopher Squires, Wayne Burri, Luca Gibelli, xfs

On 6/11/15 3:07 PM, Eric Sandeen wrote:
> On 6/11/15 11:32 AM, Török Edwin wrote:
> 
>> All commands below were run on armv7, and unmounted, the files from
>> /tmp copied over to x86-64, gzipped and uploaded, they were never
>> mounted on x86-64:
>>
>> # dd if=/dev/zero of=/tmp/xfs2.test bs=1M count=40
>> 40+0 records in
>> 40+0 records out
>> 41943040 bytes (42 MB) copied, 0.419997 s, 99.9 MB/s
>> # mkfs.xfs /tmp/xfs2.test
>> meta-data=/tmp/xfs2.test         isize=256    agcount=2, agsize=5120 blks
>>          =                       sectsz=512   attr=2, projid32bit=0
>> data     =                       bsize=4096   blocks=10240, imaxpct=25
>>          =                       sunit=0      swidth=0 blks
>> naming   =version 2              bsize=4096   ascii-ci=0
>> log      =internal log           bsize=4096   blocks=1200, version=2
>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>> # cp /tmp/xfs2.test /tmp/xfs2.test.orig
>> # umount /export/dfs
>> # mount -o loop -t xfs /tmp/xfs2.test /export/dfs
>> # mkdir /export/dfs/a
>> # sxadm node --new --batch /export/dfs/a/b
>> # ls /export/dfs/a/b
>> ls: reading directory /export/dfs/a/b: Structure needs cleaning
> 
> ok, so dir a/b/ is inode 150400
> 
> # ls -id mnt/a/b
> 150400 mnt/a/b
> 
> xfs_db> inode 150400
> xfs_db> p
> ...
> core.format = 2 (extents)
> ...
> u.bmx[0-2] = [startoff,startblock,blockcount,extentflag] 0:[0,9420,1,0] 1:[1,9553,1,0] 2:[8388608,9489,1,0]
> 
> so those are the blocks it should be reading as directory data; somehow it's finding a superblock instead (?!)
> 
> None of those physical blocks are particularly interesting; 9420, 9553, 9489 - nothing that could/should be weirdly shifted or overflowed or bit-flipped to read block 0, AFAICT.
> 
> The hexdump below has superblock magic, and this filesystem has only 2 superblocks, at fs block 0 and fs block 8192.  Nothing really in common with the 3 directory blocks above.
> 
>> # umount /export/dfs
>> # cp /tmp/xfs2.test /tmp/xfs2.test.corrupted
>> # dmesg >/tmp/dmesg
>> # exit
>>
>> the latest corruption message from dmesg:
>> [4744604.870000] XFS (loop0): Mounting Filesystem
>> [4744604.900000] XFS (loop0): Ending clean mount
>> [4745016.610000] dc61e000: 58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00  XFSB..........(.
>> [4745016.620000] dc61e010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> [4745016.630000] dc61e020: 64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9  d#..2.L .n.6..T.
>> [4745016.640000] dc61e030: 00 00 00 00 00 00 20 04 00 00 00 00 00 00 00 80  ...... .........
>> [4745016.640000] XFS (loop0): Internal error xfs_dir3_data_read_verify at line 274 of file fs/xfs/xfs_dir2_data.c.  Caller 0xc01c1528
>> [4745016.650000] CPU: 0 PID: 37 Comm: kworker/0:1H Not tainted 3.14.3-00088-g7651c68 #24
>> [4745016.650000] Workqueue: xfslogd xfs_buf_iodone_work
>> [4745016.650000] [<c0013948>] (unwind_backtrace) from [<c0011058>] (show_stack+0x10/0x14)
>> [4745016.650000] [<c0011058>] (show_stack) from [<c01c3dc4>] (xfs_corruption_error+0x54/0x70)
>> [4745016.650000] [<c01c3dc4>] (xfs_corruption_error) from [<c01f7854>] (xfs_dir3_data_read_verify+0x60/0xd0)
>> [4745016.650000] [<c01f7854>] (xfs_dir3_data_read_verify) from [<c01c1528>] (xfs_buf_iodone_work+0x7c/0x94)
>> [4745016.650000] [<c01c1528>] (xfs_buf_iodone_work) from [<c00309f0>] (process_one_work+0xf4/0x32c)
>> [4745016.650000] [<c00309f0>] (process_one_work) from [<c0030fb4>] (worker_thread+0x10c/0x388)
>> [4745016.650000] [<c0030fb4>] (worker_thread) from [<c0035e10>] (kthread+0xbc/0xd8)
>> [4745016.650000] [<c0035e10>] (kthread) from [<c000e8f8>] (ret_from_fork+0x14/0x3c)
>> [4745016.650000] XFS (loop0): Corruption detected. Unmount and run xfs_repair
>> [4745016.650000] XFS (loop0): metadata I/O error: block 0xa000 ("xfs_trans_read_buf_map") error 117 numblks 8
> 
> ok, block 0xA000 (in sectors) is sector 40960...
> 
> xfs_db> daddr 40960
> xfs_db> fsblock 
> current fsblock is 8192
> xfs_db> type text
> xfs_db> p
> 000:  58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00  XFSB............
> 010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 020:  64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9  d...2.L..n.6..T.
> 
> ...
> 
> Right, so it's reading the 2nd superblock in xfs_dir3_data_read_verify.  Huh?
> (I could have imagined some weird scenario where we read block 0, but 8192?
> Very strange).
> 
> Hm, I don't think this can be readahead, it'd not get to this verifier AFAICT.
> 
> Given that the image is enough to reproduce via just mount; ls - we should be
> able to reproduce this, given the right hardware, and get to the bottom of it.

One other thing that might help:

# trace-cmd record -e xfs\* &
# <mount the image and do the ls test>
# kill %1
# trace-cmd report > trace_report.txt

and provide that info along w/ the dmesg when it fails.
(I assume it's the same, but just to be sure)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 20:07           ` Eric Sandeen
  2015-06-11 20:29             ` Eric Sandeen
@ 2015-06-11 22:53             ` Dave Chinner
  1 sibling, 0 replies; 38+ messages in thread
From: Dave Chinner @ 2015-06-11 22:53 UTC (permalink / raw)
  To: Eric Sandeen
  Cc: Brian Foster, Luca Gibelli, xfs, Christopher Squires,
	Török Edwin, Wayne Burri

On Thu, Jun 11, 2015 at 03:07:45PM -0500, Eric Sandeen wrote:
> On 6/11/15 11:32 AM, Török Edwin wrote:
> > [4745016.650000] XFS (loop0): metadata I/O error: block 0xa000 ("xfs_trans_read_buf_map") error 117 numblks 8
> 
> ok, block 0xA000 (in sectors) is sector 40960...
> 
> xfs_db> daddr 40960
> xfs_db> fsblock 
> current fsblock is 8192
> xfs_db> type text
> xfs_db> p
> 000:  58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00  XFSB............
> 010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 020:  64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9  d...2.L..n.6..T.
> 
> ...
> 
> Right, so it's reading the 2nd superblock in xfs_dir3_data_read_verify.  Huh?
> (I could have imagined some weird scenario where we read block 0, but 8192?
> Very strange).
> 
> Hm, I don't think this can be readahead, it'd not get to this verifier AFAICT.
> 
> Given that the image is enough to reproduce via just mount; ls - we should be
> able to reproduce this, given the right hardware, and get to the bottom of it.

OK, so I've had a look at the on disk layout via xfs_db and there is
no corruption present on disk. I've confirmed that by mounting on
x86-64 (on 4.1-rc6) and no errors have been issued, and xfs_repair
(from for-next branch) doesn't see anything wrong, either.

So this is looking like either: a) a kernel bug we've subsequently
fixed; or b) an arm specific compiler or kernel bug.

I'd like to see a) ruled out as quickly as possible. Torok, can you
build a more recent kernel and see if the problem persists?

Can you also let us know what compiler version you are using and how
you are compiling (e.g. cross compile)? ISTR a previous incarnation
of this problem showed up when a specific compiler version was used
to cross-compile the armv7 kernel from x86-64, and it went away with
a compiler update. So it would be good to rule out the
compiler/build environment as the cause, too.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-11 16:32         ` Török Edwin
  2015-06-11 17:10           ` Eric Sandeen
  2015-06-11 20:07           ` Eric Sandeen
@ 2015-06-12 12:21           ` Brian Foster
  2015-06-12 12:47             ` Török Edwin
  2 siblings, 1 reply; 38+ messages in thread
From: Brian Foster @ 2015-06-12 12:21 UTC (permalink / raw)
  To: Török Edwin
  Cc: Christopher Squires, Wayne Burri, Eric Sandeen, Luca Gibelli, xfs

On Thu, Jun 11, 2015 at 07:32:04PM +0300, Török Edwin wrote:
> On 06/11/2015 06:58 PM, Eric Sandeen wrote:
> > On 6/11/15 10:51 AM, Eric Sandeen wrote:
> >> On 6/11/15 10:28 AM, Török Edwin wrote:
> >>> On 06/11/2015 06:16 PM, Brian Foster wrote:
> >>>> On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
> >>>>> [1.] XFS on ARM corruption 'Structure needs cleaning'
> >>>>> [2.] Full description of the problem/report:
> >>>>>
> >>>>> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
> >>>>>
> >>>>> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
> >>>>> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
> >>>>> and dmesg shows a corruption error [6.].
> >>>>> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
> >>>>> I still get the 'Structure needs cleaning' error.
> >>>>>
> >>>>> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
> >>>>> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
> >>>>>
> >>>>> [3.] Keywords: filesystems, XFS corruption, ARM
> >>>>> [4.] Kernel information
> >>>>> [4.1.] Kernel version (from /proc/version):
> >>>>> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
> >>>>>
> >>>> ...
> >>>>> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
> >>>>>
> >>>>> [6.] dmesg stacktrace
> >>>>>
> >>>>> [4627578.440000] XFS (sda4): Mounting Filesystem
> >>>>> [4627578.510000] XFS (sda4): Ending clean mount
> >>>>> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
> >>>>> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >>>>> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
> >>>>> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
> >>>>
> >>>> Just a data point... the magic number here looks like a superblock magic
> >>>> (XFSB) rather than one of the directory magic numbers. I'm wondering if
> >>>> a buffer disk address has gone bad somehow or another.
> >>>>
> >>>> Does this happen to be a large block device? I don't see any partition
> >>>> or xfs_info data below. If so, it would be interesting to see if this
> >>>> reproduces on a smaller device. It does appear that the large block
> >>>> device option is enabled in the kernel config above, however, so maybe
> >>>> that's unrelated.
> >>>
> >>> This is mkfs.xfs /dev/sda4:
> >>> meta-data=/dev/sda4              isize=256    agcount=4, agsize=231737408 blks
> >>>          =                       sectsz=512   attr=2, projid32bit=0
> >>> data     =                       bsize=4096   blocks=926949632, imaxpct=5
> >>>          =                       sunit=0      swidth=0 blks
> >>> naming   =version 2              bsize=4096   ascii-ci=0
> >>> log      =internal log           bsize=4096   blocks=452612, version=2
> >>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> >>> realtime =none                   extsz=4096   blocks=0, rtextents=0
> >>>
> >>> But it also reproduces with this small loopback file:
> >>> meta-data=/tmp/xfs.test          isize=256    agcount=2, agsize=5120 blks
> >>>          =                       sectsz=512   attr=2, projid32bit=0
> >>> data     =                       bsize=4096   blocks=10240, imaxpct=25
> >>>          =                       sunit=0      swidth=0 blks
> >>> naming   =version 2              bsize=4096   ascii-ci=0
> >>> log      =internal log           bsize=4096   blocks=1200, version=2
> >>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> >>> realtime =none                   extsz=4096   blocks=0, rtextents=0
> >>
> >> ok so not a block number overflow issue, thanks.
> >>
> >>> You can have a look at xfs.test here: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs.test.gz
> >>>
> >>> If I loopback mount that on an x86-64 box it doesn't show the corruption message though ...
> >>
> >> FWIW, this is the 2nd report we've had of something similar, both on Armv7, both ok on x86_64.
> >>
> >> I'll take a look at your xfs.test; that's presumably copied after it reported the error, and you unmounted it before uploading, correct?  And it was mkfs'd on armv7, never mounted or manipulated in any way on x86_64?
> 
> Thanks, yes it was mkfs.xfs on ARMv7 and unmounted.
> 
> > 
> > Oh, and what were the kernel messages when you produced the corruption with xfs.txt?
> 
> Takes only a couple of minutes to reproduce the issue so I've prepared a fresh set of xfs2.test and corresponding kernel messages to make sure its all consistent.
> Freshly created XFS by mkfs.xfs: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.orig.gz
> The corrupted XFS: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.corrupted.gz
> 

I managed to get an updated kernel on a beaglebone I had sitting around,
but I don't reproduce any errors with the "corrupted" image (I think
we've established that the image is fine on-disk and something is going
awry at runtime):

root@beaglebone:~# uname -a
Linux beaglebone 3.14.1+ #5 SMP Thu Jun 11 20:58:02 EDT 2015 armv7l GNU/Linux
root@beaglebone:~# mount ./xfs2.test.corrupted /mnt/
root@beaglebone:~# ls -al /mnt/a/
total 12
drwxr-xr-x 3 root root   14 Jun 11 16:11 .
drwxr-xr-x 3 root root   14 Jun 11 16:11 ..
drwxr-x--- 2 root root 8192 Jun 11 16:11 b
root@beaglebone:~# ls -al /mnt/a/b/
total 17996
drwxr-x--- 2 root root    8192 Jun 11 16:11 .
drwxr-xr-x 3 root root      14 Jun 11 16:11 ..
-rw-r--r-- 1 root root   12288 Jun 11 16:11 events.db
-rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000000.db
-rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000001.db
-rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000002.db
-rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000003.db
...
root@beaglebone:~#

I echo Dave's suggestion down thread with regard to toolchain. This
kernel was compiled with the following cross-gcc (installed via Fedora
package):

	gcc version 4.9.2 20150212 (Red Hat Cross 4.9.2-5) (GCC) 

Are you using something different?

Brian

> All commands below were run on armv7, and unmounted, the files from /tmp copied over to x86-64, gzipped and uploaded, they were never mounted on x86-64:
> 
> # dd if=/dev/zero of=/tmp/xfs2.test bs=1M count=40
> 40+0 records in
> 40+0 records out
> 41943040 bytes (42 MB) copied, 0.419997 s, 99.9 MB/s
> # mkfs.xfs /tmp/xfs2.test
> meta-data=/tmp/xfs2.test         isize=256    agcount=2, agsize=5120 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=4096   blocks=10240, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> # cp /tmp/xfs2.test /tmp/xfs2.test.orig
> # umount /export/dfs
> # mount -o loop -t xfs /tmp/xfs2.test /export/dfs
> # mkdir /export/dfs/a
> # sxadm node --new --batch /export/dfs/a/b
> # ls /export/dfs/a/b
> ls: reading directory /export/dfs/a/b: Structure needs cleaning
> # umount /export/dfs
> # cp /tmp/xfs2.test /tmp/xfs2.test.corrupted
> # dmesg >/tmp/dmesg
> # exit
> 
> the latest corruption message from dmesg:
> [4744604.870000] XFS (loop0): Mounting Filesystem
> [4744604.900000] XFS (loop0): Ending clean mount
> [4745016.610000] dc61e000: 58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00  XFSB..........(.
> [4745016.620000] dc61e010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> [4745016.630000] dc61e020: 64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9  d#..2.L .n.6..T.
> [4745016.640000] dc61e030: 00 00 00 00 00 00 20 04 00 00 00 00 00 00 00 80  ...... .........
> [4745016.640000] XFS (loop0): Internal error xfs_dir3_data_read_verify at line 274 of file fs/xfs/xfs_dir2_data.c.  Caller 0xc01c1528
> [4745016.650000] CPU: 0 PID: 37 Comm: kworker/0:1H Not tainted 3.14.3-00088-g7651c68 #24
> [4745016.650000] Workqueue: xfslogd xfs_buf_iodone_work
> [4745016.650000] [<c0013948>] (unwind_backtrace) from [<c0011058>] (show_stack+0x10/0x14)
> [4745016.650000] [<c0011058>] (show_stack) from [<c01c3dc4>] (xfs_corruption_error+0x54/0x70)
> [4745016.650000] [<c01c3dc4>] (xfs_corruption_error) from [<c01f7854>] (xfs_dir3_data_read_verify+0x60/0xd0)
> [4745016.650000] [<c01f7854>] (xfs_dir3_data_read_verify) from [<c01c1528>] (xfs_buf_iodone_work+0x7c/0x94)
> [4745016.650000] [<c01c1528>] (xfs_buf_iodone_work) from [<c00309f0>] (process_one_work+0xf4/0x32c)
> [4745016.650000] [<c00309f0>] (process_one_work) from [<c0030fb4>] (worker_thread+0x10c/0x388)
> [4745016.650000] [<c0030fb4>] (worker_thread) from [<c0035e10>] (kthread+0xbc/0xd8)
> [4745016.650000] [<c0035e10>] (kthread) from [<c000e8f8>] (ret_from_fork+0x14/0x3c)
> [4745016.650000] XFS (loop0): Corruption detected. Unmount and run xfs_repair
> [4745016.650000] XFS (loop0): metadata I/O error: block 0xa000 ("xfs_trans_read_buf_map") error 117 numblks 8
> 
> Best regards,
> --Edwin
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-12 12:21           ` Brian Foster
@ 2015-06-12 12:47             ` Török Edwin
  2015-06-12 13:54               ` Brian Foster
  2015-06-12 22:52               ` Dave Chinner
  0 siblings, 2 replies; 38+ messages in thread
From: Török Edwin @ 2015-06-12 12:47 UTC (permalink / raw)
  To: Brian Foster, Karanvir Singh
  Cc: Christopher Squires, Wayne Burri, Eric Sandeen, Luca Gibelli, xfs

On 06/12/2015 03:21 PM, Brian Foster wrote:
> On Thu, Jun 11, 2015 at 07:32:04PM +0300, Török Edwin wrote:
>> On 06/11/2015 06:58 PM, Eric Sandeen wrote:
>>> On 6/11/15 10:51 AM, Eric Sandeen wrote:
>>>> On 6/11/15 10:28 AM, Török Edwin wrote:
>>>>> On 06/11/2015 06:16 PM, Brian Foster wrote:
>>>>>> On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
>>>>>>> [1.] XFS on ARM corruption 'Structure needs cleaning'
>>>>>>> [2.] Full description of the problem/report:
>>>>>>>
>>>>>>> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
>>>>>>>
>>>>>>> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
>>>>>>> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
>>>>>>> and dmesg shows a corruption error [6.].
>>>>>>> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
>>>>>>> I still get the 'Structure needs cleaning' error.
>>>>>>>
>>>>>>> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
>>>>>>> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
>>>>>>>
>>>>>>> [3.] Keywords: filesystems, XFS corruption, ARM
>>>>>>> [4.] Kernel information
>>>>>>> [4.1.] Kernel version (from /proc/version):
>>>>>>> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
>>>>>>>
>>>>>> ...
>>>>>>> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
>>>>>>>
>>>>>>> [6.] dmesg stacktrace
>>>>>>>
>>>>>>> [4627578.440000] XFS (sda4): Mounting Filesystem
>>>>>>> [4627578.510000] XFS (sda4): Ending clean mount
>>>>>>> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
>>>>>>> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>>>>>> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
>>>>>>> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
>>>>>>
>>>>>> Just a data point... the magic number here looks like a superblock magic
>>>>>> (XFSB) rather than one of the directory magic numbers. I'm wondering if
>>>>>> a buffer disk address has gone bad somehow or another.
>>>>>>
>>>>>> Does this happen to be a large block device? I don't see any partition
>>>>>> or xfs_info data below. If so, it would be interesting to see if this
>>>>>> reproduces on a smaller device. It does appear that the large block
>>>>>> device option is enabled in the kernel config above, however, so maybe
>>>>>> that's unrelated.
>>>>>
>>>>> This is mkfs.xfs /dev/sda4:
>>>>> meta-data=/dev/sda4              isize=256    agcount=4, agsize=231737408 blks
>>>>>          =                       sectsz=512   attr=2, projid32bit=0
>>>>> data     =                       bsize=4096   blocks=926949632, imaxpct=5
>>>>>          =                       sunit=0      swidth=0 blks
>>>>> naming   =version 2              bsize=4096   ascii-ci=0
>>>>> log      =internal log           bsize=4096   blocks=452612, version=2
>>>>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
>>>>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>>>>>
>>>>> But it also reproduces with this small loopback file:
>>>>> meta-data=/tmp/xfs.test          isize=256    agcount=2, agsize=5120 blks
>>>>>          =                       sectsz=512   attr=2, projid32bit=0
>>>>> data     =                       bsize=4096   blocks=10240, imaxpct=25
>>>>>          =                       sunit=0      swidth=0 blks
>>>>> naming   =version 2              bsize=4096   ascii-ci=0
>>>>> log      =internal log           bsize=4096   blocks=1200, version=2
>>>>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
>>>>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>>>>
>>>> ok so not a block number overflow issue, thanks.
>>>>
>>>>> You can have a look at xfs.test here: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs.test.gz
>>>>>
>>>>> If I loopback mount that on an x86-64 box it doesn't show the corruption message though ...
>>>>
>>>> FWIW, this is the 2nd report we've had of something similar, both on Armv7, both ok on x86_64.
>>>>
>>>> I'll take a look at your xfs.test; that's presumably copied after it reported the error, and you unmounted it before uploading, correct?  And it was mkfs'd on armv7, never mounted or manipulated in any way on x86_64?
>>
>> Thanks, yes it was mkfs.xfs on ARMv7 and unmounted.
>>
>>>
>>> Oh, and what were the kernel messages when you produced the corruption with xfs.txt?
>>
>> Takes only a couple of minutes to reproduce the issue so I've prepared a fresh set of xfs2.test and corresponding kernel messages to make sure its all consistent.
>> Freshly created XFS by mkfs.xfs: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.orig.gz
>> The corrupted XFS: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.corrupted.gz
>>
> 
> I managed to get an updated kernel on a beaglebone I had sitting around,
> but I don't reproduce any errors with the "corrupted" image (I think
> we've established that the image is fine on-disk and something is going
> awry at runtime):
> 
> root@beaglebone:~# uname -a
> Linux beaglebone 3.14.1+ #5 SMP Thu Jun 11 20:58:02 EDT 2015 armv7l GNU/Linux
> root@beaglebone:~# mount ./xfs2.test.corrupted /mnt/
> root@beaglebone:~# ls -al /mnt/a/
> total 12
> drwxr-xr-x 3 root root   14 Jun 11 16:11 .
> drwxr-xr-x 3 root root   14 Jun 11 16:11 ..
> drwxr-x--- 2 root root 8192 Jun 11 16:11 b
> root@beaglebone:~# ls -al /mnt/a/b/
> total 17996
> drwxr-x--- 2 root root    8192 Jun 11 16:11 .
> drwxr-xr-x 3 root root      14 Jun 11 16:11 ..
> -rw-r--r-- 1 root root   12288 Jun 11 16:11 events.db
> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000000.db
> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000001.db
> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000002.db
> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000003.db
> ...
> root@beaglebone:~#
> 
> I echo Dave's suggestion down thread with regard to toolchain. This
> kernel was compiled with the following cross-gcc (installed via Fedora
> package):
> 
> 	gcc version 4.9.2 20150212 (Red Hat Cross 4.9.2-5) (GCC) 
> 
> Are you using something different?

/proc/version says:

Linux version 3.14.3-00088-g7651c68 (jenkins@boulder-jenkins) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #24 Thu Apr 9 16:13:46 MDT 2015

I'll get back to you when I have a new kernel running.

Best regards,
--Edwin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-12 12:47             ` Török Edwin
@ 2015-06-12 13:54               ` Brian Foster
  2015-06-12 20:19                 ` Eric Sandeen
  2015-06-12 22:52               ` Dave Chinner
  1 sibling, 1 reply; 38+ messages in thread
From: Brian Foster @ 2015-06-12 13:54 UTC (permalink / raw)
  To: Török Edwin
  Cc: Karanvir Singh, Eric Sandeen, Luca Gibelli, xfs,
	Christopher Squires, Wayne Burri

On Fri, Jun 12, 2015 at 03:47:16PM +0300, Török Edwin wrote:
> On 06/12/2015 03:21 PM, Brian Foster wrote:
> > On Thu, Jun 11, 2015 at 07:32:04PM +0300, Török Edwin wrote:
> >> On 06/11/2015 06:58 PM, Eric Sandeen wrote:
> >>> On 6/11/15 10:51 AM, Eric Sandeen wrote:
> >>>> On 6/11/15 10:28 AM, Török Edwin wrote:
> >>>>> On 06/11/2015 06:16 PM, Brian Foster wrote:
> >>>>>> On Thu, Jun 11, 2015 at 09:23:38AM +0300, Török Edwin wrote:
> >>>>>>> [1.] XFS on ARM corruption 'Structure needs cleaning'
> >>>>>>> [2.] Full description of the problem/report:
> >>>>>>>
> >>>>>>> I have been running XFS sucessfully on x86-64 for years, however I'm having trouble running it on ARM.
> >>>>>>>
> >>>>>>> Running the testcase below [7.] reliably reproduces the filesystem corruption starting from a freshly
> >>>>>>> created XFS filesystem: running ls after 'sxadm node --new --batch /export/dfs/a/b' shows a 'Structure needs cleaning' error,
> >>>>>>> and dmesg shows a corruption error [6.].
> >>>>>>> xfs_repair 3.1.9 is not able to repair the corruption: after mounting the repair filesystem
> >>>>>>> I still get the 'Structure needs cleaning' error.
> >>>>>>>
> >>>>>>> Note: using /export/dfs/a/b is important for reproducing the problem: if I only use one level of directories in /export/dfs then the problem
> >>>>>>> doesn't reproduce. Also if I use a tuned version of sxadm that creates fewer database files then the problem doesn't reproduce either.
> >>>>>>>
> >>>>>>> [3.] Keywords: filesystems, XFS corruption, ARM
> >>>>>>> [4.] Kernel information
> >>>>>>> [4.1.] Kernel version (from /proc/version):
> >>>>>>> Linux hornet34 3.14.3-00088-g7651c68 #24 Thu Apr 9 16:13:46 MDT 2015 armv7l GNU/Linux
> >>>>>>>
> >>>>>> ...
> >>>>>>> [5.] Most recent kernel version which did not have the bug: Unknown, first kernel I try on ARM
> >>>>>>>
> >>>>>>> [6.] dmesg stacktrace
> >>>>>>>
> >>>>>>> [4627578.440000] XFS (sda4): Mounting Filesystem
> >>>>>>> [4627578.510000] XFS (sda4): Ending clean mount
> >>>>>>> [4627621.470000] dd6ee000: 58 46 53 42 00 00 10 00 00 00 00 00 37 40 21 00  XFSB........7@!.
> >>>>>>> [4627621.480000] dd6ee010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >>>>>>> [4627621.490000] dd6ee020: 5b 08 7f 79 0e 3a 46 3d 9b ea 26 ad 9d 62 17 8d  [..y.:F=..&..b..
> >>>>>>> [4627621.490000] dd6ee030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80  .... ...........
> >>>>>>
> >>>>>> Just a data point... the magic number here looks like a superblock magic
> >>>>>> (XFSB) rather than one of the directory magic numbers. I'm wondering if
> >>>>>> a buffer disk address has gone bad somehow or another.
> >>>>>>
> >>>>>> Does this happen to be a large block device? I don't see any partition
> >>>>>> or xfs_info data below. If so, it would be interesting to see if this
> >>>>>> reproduces on a smaller device. It does appear that the large block
> >>>>>> device option is enabled in the kernel config above, however, so maybe
> >>>>>> that's unrelated.
> >>>>>
> >>>>> This is mkfs.xfs /dev/sda4:
> >>>>> meta-data=/dev/sda4              isize=256    agcount=4, agsize=231737408 blks
> >>>>>          =                       sectsz=512   attr=2, projid32bit=0
> >>>>> data     =                       bsize=4096   blocks=926949632, imaxpct=5
> >>>>>          =                       sunit=0      swidth=0 blks
> >>>>> naming   =version 2              bsize=4096   ascii-ci=0
> >>>>> log      =internal log           bsize=4096   blocks=452612, version=2
> >>>>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> >>>>> realtime =none                   extsz=4096   blocks=0, rtextents=0
> >>>>>
> >>>>> But it also reproduces with this small loopback file:
> >>>>> meta-data=/tmp/xfs.test          isize=256    agcount=2, agsize=5120 blks
> >>>>>          =                       sectsz=512   attr=2, projid32bit=0
> >>>>> data     =                       bsize=4096   blocks=10240, imaxpct=25
> >>>>>          =                       sunit=0      swidth=0 blks
> >>>>> naming   =version 2              bsize=4096   ascii-ci=0
> >>>>> log      =internal log           bsize=4096   blocks=1200, version=2
> >>>>>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> >>>>> realtime =none                   extsz=4096   blocks=0, rtextents=0
> >>>>
> >>>> ok so not a block number overflow issue, thanks.
> >>>>
> >>>>> You can have a look at xfs.test here: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs.test.gz
> >>>>>
> >>>>> If I loopback mount that on an x86-64 box it doesn't show the corruption message though ...
> >>>>
> >>>> FWIW, this is the 2nd report we've had of something similar, both on Armv7, both ok on x86_64.
> >>>>
> >>>> I'll take a look at your xfs.test; that's presumably copied after it reported the error, and you unmounted it before uploading, correct?  And it was mkfs'd on armv7, never mounted or manipulated in any way on x86_64?
> >>
> >> Thanks, yes it was mkfs.xfs on ARMv7 and unmounted.
> >>
> >>>
> >>> Oh, and what were the kernel messages when you produced the corruption with xfs.txt?
> >>
> >> Takes only a couple of minutes to reproduce the issue so I've prepared a fresh set of xfs2.test and corresponding kernel messages to make sure its all consistent.
> >> Freshly created XFS by mkfs.xfs: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.orig.gz
> >> The corrupted XFS: http://vol-public.s3.indian.skylable.com:8008/armel/testcase/xfs2.test.corrupted.gz
> >>
> > 
> > I managed to get an updated kernel on a beaglebone I had sitting around,
> > but I don't reproduce any errors with the "corrupted" image (I think
> > we've established that the image is fine on-disk and something is going
> > awry at runtime):
> > 
> > root@beaglebone:~# uname -a
> > Linux beaglebone 3.14.1+ #5 SMP Thu Jun 11 20:58:02 EDT 2015 armv7l GNU/Linux
> > root@beaglebone:~# mount ./xfs2.test.corrupted /mnt/
> > root@beaglebone:~# ls -al /mnt/a/
> > total 12
> > drwxr-xr-x 3 root root   14 Jun 11 16:11 .
> > drwxr-xr-x 3 root root   14 Jun 11 16:11 ..
> > drwxr-x--- 2 root root 8192 Jun 11 16:11 b
> > root@beaglebone:~# ls -al /mnt/a/b/
> > total 17996
> > drwxr-x--- 2 root root    8192 Jun 11 16:11 .
> > drwxr-xr-x 3 root root      14 Jun 11 16:11 ..
> > -rw-r--r-- 1 root root   12288 Jun 11 16:11 events.db
> > -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000000.db
> > -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000001.db
> > -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000002.db
> > -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000003.db
> > ...
> > root@beaglebone:~#
> > 
> > I echo Dave's suggestion down thread with regard to toolchain. This
> > kernel was compiled with the following cross-gcc (installed via Fedora
> > package):
> > 
> > 	gcc version 4.9.2 20150212 (Red Hat Cross 4.9.2-5) (GCC) 
> > 
> > Are you using something different?
> 
> /proc/version says:
> 
> Linux version 3.14.3-00088-g7651c68 (jenkins@boulder-jenkins) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #24 Thu Apr 9 16:13:46 MDT 2015
> 
> I'll get back to you when I have a new kernel running.
> 

Ok. FWIW, I just tried rebuilding with the following 4.6.3 toolchain:

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/x86_64-gcc-4.6.3-nolibc_arm-unknown-linux-gnueabi.tar.xz

... and still didn't reproduce any errors. Of course, this probably
doesn't have whatever patches and whatnot might be included in the
distro 4.6.3 toolchain. It could be worth a try depending on what
happens with a newer kernel, though.

Brian

> Best regards,
> --Edwin
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-12 13:54               ` Brian Foster
@ 2015-06-12 20:19                 ` Eric Sandeen
       [not found]                   ` <BLUPR04MB593340A765596780F266454F2BB0@BLUPR04MB593.namprd04.prod.outlook.com>
  0 siblings, 1 reply; 38+ messages in thread
From: Eric Sandeen @ 2015-06-12 20:19 UTC (permalink / raw)
  To: Brian Foster, Török Edwin
  Cc: Christopher Squires, Karanvir Singh, Wayne Burri, Luca Gibelli, xfs

On 6/12/15 8:54 AM, Brian Foster wrote:

>>> I managed to get an updated kernel on a beaglebone I had sitting around,
>>> but I don't reproduce any errors with the "corrupted" image (I think
>>> we've established that the image is fine on-disk and something is going
>>> awry at runtime):
>>>
>>> root@beaglebone:~# uname -a
>>> Linux beaglebone 3.14.1+ #5 SMP Thu Jun 11 20:58:02 EDT 2015 armv7l GNU/Linux
>>> root@beaglebone:~# mount ./xfs2.test.corrupted /mnt/
>>> root@beaglebone:~# ls -al /mnt/a/
>>> total 12
>>> drwxr-xr-x 3 root root   14 Jun 11 16:11 .
>>> drwxr-xr-x 3 root root   14 Jun 11 16:11 ..
>>> drwxr-x--- 2 root root 8192 Jun 11 16:11 b
>>> root@beaglebone:~# ls -al /mnt/a/b/
>>> total 17996
>>> drwxr-x--- 2 root root    8192 Jun 11 16:11 .
>>> drwxr-xr-x 3 root root      14 Jun 11 16:11 ..
>>> -rw-r--r-- 1 root root   12288 Jun 11 16:11 events.db
>>> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000000.db
>>> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000001.db
>>> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000002.db
>>> -rw-r--r-- 1 root root   15360 Jun 11 16:11 f00000003.db
>>> ...
>>> root@beaglebone:~#
>>>
>>> I echo Dave's suggestion down thread with regard to toolchain. This
>>> kernel was compiled with the following cross-gcc (installed via Fedora
>>> package):
>>>
>>> 	gcc version 4.9.2 20150212 (Red Hat Cross 4.9.2-5) (GCC) 
>>>
>>> Are you using something different?
>>
>> /proc/version says:
>>
>> Linux version 3.14.3-00088-g7651c68 (jenkins@boulder-jenkins) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #24 Thu Apr 9 16:13:46 MDT 2015
>>
>> I'll get back to you when I have a new kernel running.
>>
> 
> Ok. FWIW, I just tried rebuilding with the following 4.6.3 toolchain:
> 
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/x86_64-gcc-4.6.3-nolibc_arm-unknown-linux-gnueabi.tar.xz
> 
> ... and still didn't reproduce any errors. Of course, this probably
> doesn't have whatever patches and whatnot might be included in the
> distro 4.6.3 toolchain. It could be worth a try depending on what
> happens with a newer kernel, though.

FWIW, I tried mounting the corrupted image and running the ls on
Fedora 22, kernel 4.0.4-303.fc22.armv7hl, gcc version 5.1.1, and had no
problems there either.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-12 12:47             ` Török Edwin
  2015-06-12 13:54               ` Brian Foster
@ 2015-06-12 22:52               ` Dave Chinner
  2015-08-12  0:56                   ` katsuki.uwatoko at toshiba.co.jp
  1 sibling, 1 reply; 38+ messages in thread
From: Dave Chinner @ 2015-06-12 22:52 UTC (permalink / raw)
  To: Török Edwin
  Cc: Karanvir Singh, Brian Foster, Eric Sandeen, Luca Gibelli, xfs,
	Christopher Squires, Wayne Burri

On Fri, Jun 12, 2015 at 03:47:16PM +0300, Török Edwin wrote:
> On 06/12/2015 03:21 PM, Brian Foster wrote:
> > I echo Dave's suggestion down thread with regard to toolchain. This
> > kernel was compiled with the following cross-gcc (installed via Fedora
> > package):
> > 
> > 	gcc version 4.9.2 20150212 (Red Hat Cross 4.9.2-5) (GCC) 
> > 
> > Are you using something different?
> 
> /proc/version says:
> 
> Linux version 3.14.3-00088-g7651c68 (jenkins@boulder-jenkins) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #24 Thu Apr 9 16:13:46 MDT 2015
> 
> I'll get back to you when I have a new kernel running.

Yup, that's looking like a toolchain bug. Thread about arm directory
read corruption:

http://oss.sgi.com/archives/xfs/2013-02/msg00505.html

cross-gcc version results:

http://oss.sgi.com/archives/xfs/2013-02/msg00563.html

"A quick rundown:
  -cross-gcc4.4:  OK
  -cross-gcc4.5:  OK
  -cross-gcc4.6:  BAD
  -cross-gcc4.7:  BAD
  -cross-gcc4.8:  OK"

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
       [not found]                   ` <BLUPR04MB593340A765596780F266454F2BB0@BLUPR04MB593.namprd04.prod.outlook.com>
@ 2015-06-13 13:55                     ` Török Edwin
  0 siblings, 0 replies; 38+ messages in thread
From: Török Edwin @ 2015-06-13 13:55 UTC (permalink / raw)
  To: Eric Sandeen, Brian Foster, Dave Chinner
  Cc: Christopher Squires, Karanvir Singh, Wayne Burri, Luca Gibelli, xfs

On 06/13/2015 01:52 AM, Dave Chinner wrote:
> Yup, that's looking like a toolchain bug. Thread about arm directory
> read corruption:
> 
> http://oss.sgi.com/archives/xfs/2013-02/msg00505.html
> 
> cross-gcc version results:
> 
> http://oss.sgi.com/archives/xfs/2013-02/msg00563.html
> 
> "A quick rundown:
>   -cross-gcc4.4:  OK
>   -cross-gcc4.5:  OK
>   -cross-gcc4.6:  BAD
>   -cross-gcc4.7:  BAD
>   -cross-gcc4.8:  OK"
> 

Just tested the new kernels, they're both good:

GOOD: 3.14.3-std-00094-g9035cb4, gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1)
GOOD: 3.14.44-std-00095-g0425932, gcc version 4.9.2 (4.9.2-10)
BAD: 3.14.3-00088-g7651c68, gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)


On 06/12/2015 03:21 PM, Brian Foster wrote:
> I echo Dave's suggestion down thread with regard to toolchain. This
> kernel was compiled with the following cross-gcc (installed via Fedora
> package):
> 
> 	gcc version 4.9.2 20150212 (Red Hat Cross 4.9.2-5) (GCC) 
> 
> Are you using something different?
> 
> Brian

Indeed, it looks like a compiler bug, thanks a lot for helping me track it down.
I'll see if I can find out more about whats different between the two kernels compiled by 4.6 and 4.7.

On 06/13/2015 12:41 AM, Karanvir Singh wrote:
> 
> Hi Edwin,
> 
> 
> PFA the  newer uimages: 
> 
> uImage3.14.44.gcc.4.9.2:  its a 3.14.44 compiled with gcc 4.9.4 
> uImage.gcc.4.7.2-1: its 3.14.3 compiled with gcc 4.7.2

Thanks, both of these images work correctly: I was not able to reproduce the bug with them (rebooting to the original uImage 3.14.3 with gcc 4.6.3 reproduces bug immediately).

Best regards,
--Edwin


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-06-12 22:52               ` Dave Chinner
@ 2015-08-12  0:56                   ` katsuki.uwatoko at toshiba.co.jp
  0 siblings, 0 replies; 38+ messages in thread
From: katsuki.uwatoko @ 2015-08-12  0:56 UTC (permalink / raw)
  To: xfs, linux-arm-kernel, david
  Cc: gangchen, linux, karanvir.singh, bfoster, sandeen, luca,
	christopher.squires, edwin, wayne.burri

On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:

> Yup, that's looking like a toolchain bug. Thread about arm directory
> read corruption:

I think that this is not a toolchain bug, this is related to 
Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
http://www.spinics.net/lists/arm-kernel/msg426684.html

--

The problematic line in xfs is: 
irecs->br_startblock = XFS_DADDR_TO_FSB(mp, mappedbno)
in xfs_dabuf_map()/fs/xfs/xfs_da_btree.c.

The expansion of it is: 

  ld = mappedbno >> mp->m_blkbb_log;
  do_div(ld, mp->m_sb.sb_agblocks);
  startblock = ld << mp->m_sb.sb_agblklog;
  ld = mappedbno >> mp->m_blkbb_log;
  startblock |= do_div(ld, mp->m_sb.sb_agblocks);
  irecs->br_startblock = startblock;

The assembler of these are:

:
	bl	__do_div64
	ldr	r1, [sp, #44]
	subs	r3, r7, #32
	orr	r1, r1, r2, lsr r5
	add	r5, sp, #80
	str	r5, [sp, #64]
	ldr	r5, [sp, #60]
	movpl	r1, r2, asl r3
	mov	r2, r2, asl r7
	str	r2, [sp, #40]
	str	r1, [sp, #44]
	mov	r1, r9
	str	r5, [sp, #96]
	mov	r7, #0
	ldr	r2, [sp, #96]
	mov	r5, #1
	ldr	fp, [sp, #64]
	str	r7, [sp, #84]
	mov	r9, r2, asr #31
	str	r7, [sp, #104]
	bl	__do_div64
:

by GCC 4.7.2 with -O2 option.

Because a result of do_div is stored in the 1st arg (r0),
r0, which is "ld" in the C,  must be reloaded after the 1st call of do_div, before the 2nd call of do_div.
But it is not reloaded in the above assembler.
The problem is macro __do_div_asm, as the patch describes.

I confirmed that the patch fixed this problem.

	mov	r1, sl
	str	r2, [sp, #56]
	mov	r0, fp
	bl	__do_div64
	ldr	ip, [sp, #36]
	rsb	r6, r5, #32
	subs	r3, r5, #32
	ldr	r1, [sp, #56]
	orr	ip, ip, r2, lsr r6
	str	r7, [sp, #96]
	mov	r6, #1
	str	r8, [sp, #80]
	mov	r0, ip
	str	r1, [sp, #52]
	movpl	r0, r2, asl r3
	mov	r2, r2, asl r5
	str	r0, [sp, #36]
	mov	r1, sl
	str	r2, [sp, #32]
	mov	r0, fp
	bl	__do_div64

by GCC 4.7.2 with -O2 option and the patch.

Thank you,
-- 
UWATOKO
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12  0:56                   ` katsuki.uwatoko at toshiba.co.jp
  0 siblings, 0 replies; 38+ messages in thread
From: katsuki.uwatoko at toshiba.co.jp @ 2015-08-12  0:56 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:

> Yup, that's looking like a toolchain bug. Thread about arm directory
> read corruption:

I think that this is not a toolchain bug, this is related to 
Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
http://www.spinics.net/lists/arm-kernel/msg426684.html

--

The problematic line in xfs is: 
irecs->br_startblock = XFS_DADDR_TO_FSB(mp, mappedbno)
in xfs_dabuf_map()/fs/xfs/xfs_da_btree.c.

The expansion of it is: 

  ld = mappedbno >> mp->m_blkbb_log;
  do_div(ld, mp->m_sb.sb_agblocks);
  startblock = ld << mp->m_sb.sb_agblklog;
  ld = mappedbno >> mp->m_blkbb_log;
  startblock |= do_div(ld, mp->m_sb.sb_agblocks);
  irecs->br_startblock = startblock;

The assembler of these are:

:
	bl	__do_div64
	ldr	r1, [sp, #44]
	subs	r3, r7, #32
	orr	r1, r1, r2, lsr r5
	add	r5, sp, #80
	str	r5, [sp, #64]
	ldr	r5, [sp, #60]
	movpl	r1, r2, asl r3
	mov	r2, r2, asl r7
	str	r2, [sp, #40]
	str	r1, [sp, #44]
	mov	r1, r9
	str	r5, [sp, #96]
	mov	r7, #0
	ldr	r2, [sp, #96]
	mov	r5, #1
	ldr	fp, [sp, #64]
	str	r7, [sp, #84]
	mov	r9, r2, asr #31
	str	r7, [sp, #104]
	bl	__do_div64
:

by GCC 4.7.2 with -O2 option.

Because a result of do_div is stored in the 1st arg (r0),
r0, which is "ld" in the C,  must be reloaded after the 1st call of do_div, before the 2nd call of do_div.
But it is not reloaded in the above assembler.
The problem is macro __do_div_asm, as the patch describes.

I confirmed that the patch fixed this problem.

	mov	r1, sl
	str	r2, [sp, #56]
	mov	r0, fp
	bl	__do_div64
	ldr	ip, [sp, #36]
	rsb	r6, r5, #32
	subs	r3, r5, #32
	ldr	r1, [sp, #56]
	orr	ip, ip, r2, lsr r6
	str	r7, [sp, #96]
	mov	r6, #1
	str	r8, [sp, #80]
	mov	r0, ip
	str	r1, [sp, #52]
	movpl	r0, r2, asl r3
	mov	r2, r2, asl r5
	str	r0, [sp, #36]
	mov	r1, sl
	str	r2, [sp, #32]
	mov	r0, fp
	bl	__do_div64

by GCC 4.7.2 with -O2 option and the patch.

Thank you,
-- 
UWATOKO

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12  0:56                   ` katsuki.uwatoko at toshiba.co.jp
@ 2015-08-12  3:14                     ` Dave Chinner
  -1 siblings, 0 replies; 38+ messages in thread
From: Dave Chinner @ 2015-08-12  3:14 UTC (permalink / raw)
  To: katsuki.uwatoko
  Cc: gangchen, linux, karanvir.singh, bfoster, sandeen, luca, xfs,
	christopher.squires, edwin, wayne.burri, linux-arm-kernel

On Wed, Aug 12, 2015 at 12:56:25AM +0000, katsuki.uwatoko@toshiba.co.jp wrote:
> On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:
> 
> > Yup, that's looking like a toolchain bug. Thread about arm directory
> > read corruption:
> 
> I think that this is not a toolchain bug, this is related to 
> Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
> http://www.spinics.net/lists/arm-kernel/msg426684.html

Interesting! Very good work finding that bug, Katsuki-san. 

FWIW, I suspect this fix will need to go back into stable kernels,
too.

> --
> 
> The problematic line in xfs is: 
> irecs->br_startblock = XFS_DADDR_TO_FSB(mp, mappedbno)
> in xfs_dabuf_map()/fs/xfs/xfs_da_btree.c.
> 
> The expansion of it is: 
> 
>   ld = mappedbno >> mp->m_blkbb_log;
>   do_div(ld, mp->m_sb.sb_agblocks);
>   startblock = ld << mp->m_sb.sb_agblklog;
>   ld = mappedbno >> mp->m_blkbb_log;
>   startblock |= do_div(ld, mp->m_sb.sb_agblocks);
>   irecs->br_startblock = startblock;
> 
> The assembler of these are:
> 
> :
> 	bl	__do_div64
> 	ldr	r1, [sp, #44]
> 	subs	r3, r7, #32
> 	orr	r1, r1, r2, lsr r5
> 	add	r5, sp, #80
> 	str	r5, [sp, #64]
> 	ldr	r5, [sp, #60]
> 	movpl	r1, r2, asl r3
> 	mov	r2, r2, asl r7
> 	str	r2, [sp, #40]
> 	str	r1, [sp, #44]
> 	mov	r1, r9
> 	str	r5, [sp, #96]
> 	mov	r7, #0
> 	ldr	r2, [sp, #96]
> 	mov	r5, #1
> 	ldr	fp, [sp, #64]
> 	str	r7, [sp, #84]
> 	mov	r9, r2, asr #31
> 	str	r7, [sp, #104]
> 	bl	__do_div64
> :
> 
> by GCC 4.7.2 with -O2 option.

To close the loop, what code do the other versions GCC produce for
this macro?  Evidence so far says that the result depends on the
compiler version, so I would like to have confirmation that other
versions of the compiler generate working code.  There are other
XFS_DADDR_TO_FSB() calls in the XFS code, too - do they demonstrate
the same problem, maybe with different compiler versions?

Basically I'm asking what is the scope of the problem you've found?
i.e. when was the bug introduced, what compilers expose it, etc
so that when ARM users report XFS corruptions we have some idea of
whether their kernel/compiler combination might have caused the
issue they are seeing...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12  3:14                     ` Dave Chinner
  0 siblings, 0 replies; 38+ messages in thread
From: Dave Chinner @ 2015-08-12  3:14 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Aug 12, 2015 at 12:56:25AM +0000, katsuki.uwatoko at toshiba.co.jp wrote:
> On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:
> 
> > Yup, that's looking like a toolchain bug. Thread about arm directory
> > read corruption:
> 
> I think that this is not a toolchain bug, this is related to 
> Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
> http://www.spinics.net/lists/arm-kernel/msg426684.html

Interesting! Very good work finding that bug, Katsuki-san. 

FWIW, I suspect this fix will need to go back into stable kernels,
too.

> --
> 
> The problematic line in xfs is: 
> irecs->br_startblock = XFS_DADDR_TO_FSB(mp, mappedbno)
> in xfs_dabuf_map()/fs/xfs/xfs_da_btree.c.
> 
> The expansion of it is: 
> 
>   ld = mappedbno >> mp->m_blkbb_log;
>   do_div(ld, mp->m_sb.sb_agblocks);
>   startblock = ld << mp->m_sb.sb_agblklog;
>   ld = mappedbno >> mp->m_blkbb_log;
>   startblock |= do_div(ld, mp->m_sb.sb_agblocks);
>   irecs->br_startblock = startblock;
> 
> The assembler of these are:
> 
> :
> 	bl	__do_div64
> 	ldr	r1, [sp, #44]
> 	subs	r3, r7, #32
> 	orr	r1, r1, r2, lsr r5
> 	add	r5, sp, #80
> 	str	r5, [sp, #64]
> 	ldr	r5, [sp, #60]
> 	movpl	r1, r2, asl r3
> 	mov	r2, r2, asl r7
> 	str	r2, [sp, #40]
> 	str	r1, [sp, #44]
> 	mov	r1, r9
> 	str	r5, [sp, #96]
> 	mov	r7, #0
> 	ldr	r2, [sp, #96]
> 	mov	r5, #1
> 	ldr	fp, [sp, #64]
> 	str	r7, [sp, #84]
> 	mov	r9, r2, asr #31
> 	str	r7, [sp, #104]
> 	bl	__do_div64
> :
> 
> by GCC 4.7.2 with -O2 option.

To close the loop, what code do the other versions GCC produce for
this macro?  Evidence so far says that the result depends on the
compiler version, so I would like to have confirmation that other
versions of the compiler generate working code.  There are other
XFS_DADDR_TO_FSB() calls in the XFS code, too - do they demonstrate
the same problem, maybe with different compiler versions?

Basically I'm asking what is the scope of the problem you've found?
i.e. when was the bug introduced, what compilers expose it, etc
so that when ARM users report XFS corruptions we have some idea of
whether their kernel/compiler combination might have caused the
issue they are seeing...

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12  3:14                     ` Dave Chinner
@ 2015-08-12  6:19                       ` katsuki.uwatoko at toshiba.co.jp
  -1 siblings, 0 replies; 38+ messages in thread
From: katsuki.uwatoko @ 2015-08-12  6:19 UTC (permalink / raw)
  To: david
  Cc: gangchen, linux, karanvir.singh, bfoster, sandeen, luca, xfs,
	christopher.squires, edwin, wayne.burri, linux-arm-kernel

On Wed, 12 Aug 2015 13:14:07 +1000, Dave Chinner wrote:

> To close the loop, what code do the other versions GCC produce for
> this macro?  Evidence so far says that the result depends on the
> compiler version, so I would like to have confirmation that other
> versions of the compiler generate working code.  There are other
> XFS_DADDR_TO_FSB() calls in the XFS code, too - do they demonstrate
> the same problem, maybe with different compiler versions?
> 
> Basically I'm asking what is the scope of the problem you've found?
> i.e. when was the bug introduced, what compilers expose it, etc
> so that when ARM users report XFS corruptions we have some idea of
> whether their kernel/compiler combination might have caused the
> issue they are seeing...

I have the following versions of GCC now.
	4.5.1
	4.6.4
	4.7.2
# Sorry I don't have the recent versions of GCC.

And the results are:
	4.5.1 (-O2)	OK.
	4.6.4 (-O2)	BAD.
	4.7.2 (-O2)	BAD.

But even using gcc 4.7, this bug does not happen with -Os instead of -O2.
It means that when CONFIG_CC_OPTIMIZE_FOR_SIZE Kernel option is used, it does not happen.

As for the version of kernel, I am using 3.10 now. At least. it is the same as 2.6.32.

--
The following are codes generated by GCCs.

GCC 4.5.1 with -O2 (OK)
     178:       41a00003        movmi   r0, r3
     17c:       51a00057        asrpl   r0, r7, r0
     180:       e58da02c        str     sl, [sp, #44]   ; 0x2c
     184:       ebfffffe        bl      0 <__do_div64>
     188:       e1cd26f8        strd    r2, [sp, #104]  ; 0x68
     18c:       e3a08000        mov     r8, #0
     190:       e5d51175        ldrb    r1, [r5, #373]  ; 0x175
     194:       e59d2068        ldr     r2, [sp, #104]  ; 0x68
     198:       e251e020        subs    lr, r1, #32
     19c:       e5d5308c        ldrb    r3, [r5, #140]  ; 0x8c
     1a0:       e261c020        rsb     ip, r1, #32
     1a4:       e1a00136        lsr     r0, r6, r1
     1a8:       e1800c17        orr     r0, r0, r7, lsl ip
     1ac:       e2634020        rsb     r4, r3, #32
     1b0:       51a00e57        asrpl   r0, r7, lr
     1b4:       e253c020        subs    ip, r3, #32
     1b8:       e1a0b432        lsr     fp, r2, r4
     1bc:       e1a0a312        lsl     sl, r2, r3
     1c0:       51a0bc12        lslpl   fp, r2, ip
     1c4:       e59dc024        ldr     ip, [sp, #36]   ; 0x24
     1c8:       e5954064        ldr     r4, [r5, #100]  ; 0x64
     1cc:       e1a01157        asr     r1, r7, r1
     1d0:       e58d804c        str     r8, [sp, #76]   ; 0x4c
     1d4:       e58dc048        str     ip, [sp, #72]   ; 0x48
     1d8:       ebfffffe        bl      0 <__do_div64>

GCC 4.6.4 with -O2 (BAD)
     19c:       51a0025e        asrpl   r0, lr, r2
     1a0:       e3a0a001        mov     sl, #1
     1a4:       ebfffffe        bl      0 <__do_div64>
     1a8:       e1a0bb32        lsr     fp, r2, fp
     1ac:       e2553020        subs    r3, r5, #32
     1b0:       e1a01008        mov     r1, r8
     1b4:       e58d704c        str     r7, [sp, #76]   ; 0x4c
     1b8:       e1a0800b        mov     r8, fp
     1bc:       e58d7060        str     r7, [sp, #96]   ; 0x60
     1c0:       51a08312        lslpl   r8, r2, r3
     1c4:       e1a02512        lsl     r2, r2, r5
     1c8:       e58d8034        str     r8, [sp, #52]   ; 0x34
     1cc:       e1a0500a        mov     r5, sl
     1d0:       e58d2030        str     r2, [sp, #48]   ; 0x30
     1d4:       e28d8048        add     r8, sp, #72     ; 0x48
     1d8:       ebfffffe        bl      0 <__do_div64>

GCC 4.7.2 with -Os (OK)
     1a0:       e1cd02d8        ldrd    r0, [sp, #40]   ; 0x28
     1a4:       e1a0200b        mov     r2, fp
     1a8:       ebfffffe        bl      0 <__aeabi_lasr>
     1ac:       e5954064        ldr     r4, [r5, #100]  ; 0x64
     1b0:       ebfffffe        bl      0 <__do_div64>
     1b4:       e3a01000        mov     r1, #0
     1b8:       e1a00002        mov     r0, r2
     1bc:       e5d5208c        ldrb    r2, [r5, #140]  ; 0x8c
     1c0:       ebfffffe        bl      0 <__aeabi_llsl>
     1c4:       e1a0200b        mov     r2, fp
     1c8:       e1a06000        mov     r6, r0
     1cc:       e1a07001        mov     r7, r1
     1d0:       e1cd02d8        ldrd    r0, [sp, #40]   ; 0x28
     1d4:       ebfffffe        bl      0 <__aeabi_lasr>
     1d8:       e58da040        str     sl, [sp, #64]   ; 0x40
     1dc:       ebfffffe        bl      0 <__do_div64>

Thank you,
-- 
UWATOKO
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 38+ messages in thread

* PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12  6:19                       ` katsuki.uwatoko at toshiba.co.jp
  0 siblings, 0 replies; 38+ messages in thread
From: katsuki.uwatoko at toshiba.co.jp @ 2015-08-12  6:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 12 Aug 2015 13:14:07 +1000, Dave Chinner wrote:

> To close the loop, what code do the other versions GCC produce for
> this macro?  Evidence so far says that the result depends on the
> compiler version, so I would like to have confirmation that other
> versions of the compiler generate working code.  There are other
> XFS_DADDR_TO_FSB() calls in the XFS code, too - do they demonstrate
> the same problem, maybe with different compiler versions?
> 
> Basically I'm asking what is the scope of the problem you've found?
> i.e. when was the bug introduced, what compilers expose it, etc
> so that when ARM users report XFS corruptions we have some idea of
> whether their kernel/compiler combination might have caused the
> issue they are seeing...

I have the following versions of GCC now.
	4.5.1
	4.6.4
	4.7.2
# Sorry I don't have the recent versions of GCC.

And the results are:
	4.5.1 (-O2)	OK.
	4.6.4 (-O2)	BAD.
	4.7.2 (-O2)	BAD.

But even using gcc 4.7, this bug does not happen with -Os instead of -O2.
It means that when CONFIG_CC_OPTIMIZE_FOR_SIZE Kernel option is used, it does not happen.

As for the version of kernel, I am using 3.10 now. At least. it is the same as 2.6.32.

--
The following are codes generated by GCCs.

GCC 4.5.1 with -O2 (OK)
     178:       41a00003        movmi   r0, r3
     17c:       51a00057        asrpl   r0, r7, r0
     180:       e58da02c        str     sl, [sp, #44]   ; 0x2c
     184:       ebfffffe        bl      0 <__do_div64>
     188:       e1cd26f8        strd    r2, [sp, #104]  ; 0x68
     18c:       e3a08000        mov     r8, #0
     190:       e5d51175        ldrb    r1, [r5, #373]  ; 0x175
     194:       e59d2068        ldr     r2, [sp, #104]  ; 0x68
     198:       e251e020        subs    lr, r1, #32
     19c:       e5d5308c        ldrb    r3, [r5, #140]  ; 0x8c
     1a0:       e261c020        rsb     ip, r1, #32
     1a4:       e1a00136        lsr     r0, r6, r1
     1a8:       e1800c17        orr     r0, r0, r7, lsl ip
     1ac:       e2634020        rsb     r4, r3, #32
     1b0:       51a00e57        asrpl   r0, r7, lr
     1b4:       e253c020        subs    ip, r3, #32
     1b8:       e1a0b432        lsr     fp, r2, r4
     1bc:       e1a0a312        lsl     sl, r2, r3
     1c0:       51a0bc12        lslpl   fp, r2, ip
     1c4:       e59dc024        ldr     ip, [sp, #36]   ; 0x24
     1c8:       e5954064        ldr     r4, [r5, #100]  ; 0x64
     1cc:       e1a01157        asr     r1, r7, r1
     1d0:       e58d804c        str     r8, [sp, #76]   ; 0x4c
     1d4:       e58dc048        str     ip, [sp, #72]   ; 0x48
     1d8:       ebfffffe        bl      0 <__do_div64>

GCC 4.6.4 with -O2 (BAD)
     19c:       51a0025e        asrpl   r0, lr, r2
     1a0:       e3a0a001        mov     sl, #1
     1a4:       ebfffffe        bl      0 <__do_div64>
     1a8:       e1a0bb32        lsr     fp, r2, fp
     1ac:       e2553020        subs    r3, r5, #32
     1b0:       e1a01008        mov     r1, r8
     1b4:       e58d704c        str     r7, [sp, #76]   ; 0x4c
     1b8:       e1a0800b        mov     r8, fp
     1bc:       e58d7060        str     r7, [sp, #96]   ; 0x60
     1c0:       51a08312        lslpl   r8, r2, r3
     1c4:       e1a02512        lsl     r2, r2, r5
     1c8:       e58d8034        str     r8, [sp, #52]   ; 0x34
     1cc:       e1a0500a        mov     r5, sl
     1d0:       e58d2030        str     r2, [sp, #48]   ; 0x30
     1d4:       e28d8048        add     r8, sp, #72     ; 0x48
     1d8:       ebfffffe        bl      0 <__do_div64>

GCC 4.7.2 with -Os (OK)
     1a0:       e1cd02d8        ldrd    r0, [sp, #40]   ; 0x28
     1a4:       e1a0200b        mov     r2, fp
     1a8:       ebfffffe        bl      0 <__aeabi_lasr>
     1ac:       e5954064        ldr     r4, [r5, #100]  ; 0x64
     1b0:       ebfffffe        bl      0 <__do_div64>
     1b4:       e3a01000        mov     r1, #0
     1b8:       e1a00002        mov     r0, r2
     1bc:       e5d5208c        ldrb    r2, [r5, #140]  ; 0x8c
     1c0:       ebfffffe        bl      0 <__aeabi_llsl>
     1c4:       e1a0200b        mov     r2, fp
     1c8:       e1a06000        mov     r6, r0
     1cc:       e1a07001        mov     r7, r1
     1d0:       e1cd02d8        ldrd    r0, [sp, #40]   ; 0x28
     1d4:       ebfffffe        bl      0 <__aeabi_lasr>
     1d8:       e58da040        str     sl, [sp, #64]   ; 0x40
     1dc:       ebfffffe        bl      0 <__do_div64>

Thank you,
-- 
UWATOKO

^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12  0:56                   ` katsuki.uwatoko at toshiba.co.jp
@ 2015-08-12  6:24                     ` Christoph Hellwig
  -1 siblings, 0 replies; 38+ messages in thread
From: Christoph Hellwig @ 2015-08-12  6:24 UTC (permalink / raw)
  To: katsuki.uwatoko
  Cc: linux-arm-kernel, david, gangchen, linux, karanvir.singh, luca,
	christopher.squires, edwin, wayne.burri, linux-kernel,
	Linus Torvalds

On Wed, Aug 12, 2015 at 12:56:25AM +0000, katsuki.uwatoko@toshiba.co.jp wrote:
> On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:
> 
> > Yup, that's looking like a toolchain bug. Thread about arm directory
> > read corruption:
> 
> I think that this is not a toolchain bug, this is related to 
> Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
> http://www.spinics.net/lists/arm-kernel/msg426684.html

Maybe it's time to rely on gcc to handle 64 bit divisions now?

I've been pretty annoyed at the amount of 32-bit architecture build
failures due to the lack of support for native 64-bit divisions, and
the ugly do_div hackery to work around it.

We're living in a world where we are using a lot of 64-bit CPUs and
people optimize for them, so it might be a good time to start relying
on the compiler to get these right on older CPUs.

How bad is gcc's code for 64-bit divisions on arm and x86 these days?
Is there still a good case for offloading work the compiler should be
doing on the programmer?

^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12  6:24                     ` Christoph Hellwig
  0 siblings, 0 replies; 38+ messages in thread
From: Christoph Hellwig @ 2015-08-12  6:24 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Aug 12, 2015 at 12:56:25AM +0000, katsuki.uwatoko at toshiba.co.jp wrote:
> On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:
> 
> > Yup, that's looking like a toolchain bug. Thread about arm directory
> > read corruption:
> 
> I think that this is not a toolchain bug, this is related to 
> Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
> http://www.spinics.net/lists/arm-kernel/msg426684.html

Maybe it's time to rely on gcc to handle 64 bit divisions now?

I've been pretty annoyed at the amount of 32-bit architecture build
failures due to the lack of support for native 64-bit divisions, and
the ugly do_div hackery to work around it.

We're living in a world where we are using a lot of 64-bit CPUs and
people optimize for them, so it might be a good time to start relying
on the compiler to get these right on older CPUs.

How bad is gcc's code for 64-bit divisions on arm and x86 these days?
Is there still a good case for offloading work the compiler should be
doing on the programmer?

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12  6:24                     ` Christoph Hellwig
@ 2015-08-12 15:49                       ` Linus Torvalds
  -1 siblings, 0 replies; 38+ messages in thread
From: Linus Torvalds @ 2015-08-12 15:49 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: katsuki.uwatoko, linux-arm-kernel, Dave Chinner, gangchen,
	Russell King - ARM Linux, karanvir.singh, luca,
	christopher.squires, edwin, wayne.burri,
	Linux Kernel Mailing List

On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
>
> Maybe it's time to rely on gcc to handle 64 bit divisions now?

Ugh. gcc still does a pretty horrible job at it. While gcc knows that
a widening 32x32->64 multiplication can be simplified, it doesn't do
the same thing for a 64/32->64 division, and always calls __udivdi3
for it.

Now, __udivdi3 does avoid the general nasty case by then testing the
upper 32 bits of the divisor against zero, so it's not entirely
disastrous. It's just ugly.

But perhaps more importantly, I'm not at all sure libgcc is
kernel-safe. In particular, I'm not at all sure it *remains*
kernel-safe. Just as an example: can you guarantee that libgcc doesn't
implement integer division on some architecture by using the FP
hardware?

There's been a few cases where not having libgcc saved us headaches. I
forget the exact details, but it was something like several years ago
that we had gcc start to generate some insane crap exception handling
for C code generation, and the fact that we didn't include libgcc was
what made us catch it because of the resulting link error.

libgcc just isn't reliable in kernel space. I'm not opposed to some
random architecture using it (arch/tile does include "-lgcc" for
example), but I _do_ object to the notion that we say "let's use
libgcc in general".

So no. I do not believe that the occasional pain of a few people who
do 64-bit divides incorrectly is a good enough argument to start using
libgcc.

                 Linus

^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12 15:49                       ` Linus Torvalds
  0 siblings, 0 replies; 38+ messages in thread
From: Linus Torvalds @ 2015-08-12 15:49 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
>
> Maybe it's time to rely on gcc to handle 64 bit divisions now?

Ugh. gcc still does a pretty horrible job at it. While gcc knows that
a widening 32x32->64 multiplication can be simplified, it doesn't do
the same thing for a 64/32->64 division, and always calls __udivdi3
for it.

Now, __udivdi3 does avoid the general nasty case by then testing the
upper 32 bits of the divisor against zero, so it's not entirely
disastrous. It's just ugly.

But perhaps more importantly, I'm not at all sure libgcc is
kernel-safe. In particular, I'm not at all sure it *remains*
kernel-safe. Just as an example: can you guarantee that libgcc doesn't
implement integer division on some architecture by using the FP
hardware?

There's been a few cases where not having libgcc saved us headaches. I
forget the exact details, but it was something like several years ago
that we had gcc start to generate some insane crap exception handling
for C code generation, and the fact that we didn't include libgcc was
what made us catch it because of the resulting link error.

libgcc just isn't reliable in kernel space. I'm not opposed to some
random architecture using it (arch/tile does include "-lgcc" for
example), but I _do_ object to the notion that we say "let's use
libgcc in general".

So no. I do not believe that the occasional pain of a few people who
do 64-bit divides incorrectly is a good enough argument to start using
libgcc.

                 Linus

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12 15:49                       ` Linus Torvalds
@ 2015-08-12 22:20                         ` Andy Lutomirski
  -1 siblings, 0 replies; 38+ messages in thread
From: Andy Lutomirski @ 2015-08-12 22:20 UTC (permalink / raw)
  To: Linus Torvalds, Christoph Hellwig
  Cc: katsuki.uwatoko, linux-arm-kernel, Dave Chinner, gangchen,
	Russell King - ARM Linux, karanvir.singh, luca,
	christopher.squires, edwin, wayne.burri,
	Linux Kernel Mailing List

On 08/12/2015 08:49 AM, Linus Torvalds wrote:
> On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
>>
>> Maybe it's time to rely on gcc to handle 64 bit divisions now?
>
> Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> a widening 32x32->64 multiplication can be simplified, it doesn't do
> the same thing for a 64/32->64 division, and always calls __udivdi3
> for it.
>
> Now, __udivdi3 does avoid the general nasty case by then testing the
> upper 32 bits of the divisor against zero, so it's not entirely
> disastrous. It's just ugly.
>
> But perhaps more importantly, I'm not at all sure libgcc is
> kernel-safe. In particular, I'm not at all sure it *remains*
> kernel-safe. Just as an example: can you guarantee that libgcc doesn't
> implement integer division on some architecture by using the FP
> hardware?
>
> There's been a few cases where not having libgcc saved us headaches. I
> forget the exact details, but it was something like several years ago
> that we had gcc start to generate some insane crap exception handling
> for C code generation, and the fact that we didn't include libgcc was
> what made us catch it because of the resulting link error.
>
> libgcc just isn't reliable in kernel space. I'm not opposed to some
> random architecture using it (arch/tile does include "-lgcc" for
> example), but I _do_ object to the notion that we say "let's use
> libgcc in general".
>
> So no. I do not believe that the occasional pain of a few people who
> do 64-bit divides incorrectly is a good enough argument to start using
> libgcc.
>

Does your objection still apply if we supplied our own implementations 
of a handful of libgcc helpers?

--Andy

>                   Linus
>


^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12 22:20                         ` Andy Lutomirski
  0 siblings, 0 replies; 38+ messages in thread
From: Andy Lutomirski @ 2015-08-12 22:20 UTC (permalink / raw)
  To: linux-arm-kernel

On 08/12/2015 08:49 AM, Linus Torvalds wrote:
> On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
>>
>> Maybe it's time to rely on gcc to handle 64 bit divisions now?
>
> Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> a widening 32x32->64 multiplication can be simplified, it doesn't do
> the same thing for a 64/32->64 division, and always calls __udivdi3
> for it.
>
> Now, __udivdi3 does avoid the general nasty case by then testing the
> upper 32 bits of the divisor against zero, so it's not entirely
> disastrous. It's just ugly.
>
> But perhaps more importantly, I'm not at all sure libgcc is
> kernel-safe. In particular, I'm not at all sure it *remains*
> kernel-safe. Just as an example: can you guarantee that libgcc doesn't
> implement integer division on some architecture by using the FP
> hardware?
>
> There's been a few cases where not having libgcc saved us headaches. I
> forget the exact details, but it was something like several years ago
> that we had gcc start to generate some insane crap exception handling
> for C code generation, and the fact that we didn't include libgcc was
> what made us catch it because of the resulting link error.
>
> libgcc just isn't reliable in kernel space. I'm not opposed to some
> random architecture using it (arch/tile does include "-lgcc" for
> example), but I _do_ object to the notion that we say "let's use
> libgcc in general".
>
> So no. I do not believe that the occasional pain of a few people who
> do 64-bit divides incorrectly is a good enough argument to start using
> libgcc.
>

Does your objection still apply if we supplied our own implementations 
of a handful of libgcc helpers?

--Andy

>                   Linus
>

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12 22:20                         ` Andy Lutomirski
@ 2015-08-12 22:36                           ` Linus Torvalds
  -1 siblings, 0 replies; 38+ messages in thread
From: Linus Torvalds @ 2015-08-12 22:36 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Christoph Hellwig, katsuki.uwatoko, linux-arm-kernel,
	Dave Chinner, gangchen, Russell King - ARM Linux, karanvir.singh,
	luca, christopher.squires, edwin, wayne.burri,
	Linux Kernel Mailing List

On Wed, Aug 12, 2015 at 3:20 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> Does your objection still apply if we supplied our own implementations of a
> handful of libgcc helpers?

We already do that.

Several architectures actually implement _udivdi3.

However, do_div() is actually the much simpler/better interface.

I don't think we have a single case in the kernel where we really want
the full 64/64 division, and the 64/32->64 case really is
fundamentally simpler.

This whole "do_div is so complicated" thing is just BS.

The thing that triggered Christoph to ask was a bug in the
implementation of that *simpler*  interface. What makes you think that
making people implement _udivdi3 would magically avoid all such bugs?

                Linus

^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12 22:36                           ` Linus Torvalds
  0 siblings, 0 replies; 38+ messages in thread
From: Linus Torvalds @ 2015-08-12 22:36 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Aug 12, 2015 at 3:20 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> Does your objection still apply if we supplied our own implementations of a
> handful of libgcc helpers?

We already do that.

Several architectures actually implement _udivdi3.

However, do_div() is actually the much simpler/better interface.

I don't think we have a single case in the kernel where we really want
the full 64/64 division, and the 64/32->64 case really is
fundamentally simpler.

This whole "do_div is so complicated" thing is just BS.

The thing that triggered Christoph to ask was a bug in the
implementation of that *simpler*  interface. What makes you think that
making people implement _udivdi3 would magically avoid all such bugs?

                Linus

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12 22:36                           ` Linus Torvalds
@ 2015-08-12 22:39                             ` Andy Lutomirski
  -1 siblings, 0 replies; 38+ messages in thread
From: Andy Lutomirski @ 2015-08-12 22:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Christoph Hellwig, katsuki.uwatoko,
	linux-arm-kernel, Dave Chinner, gangchen,
	Russell King - ARM Linux, karanvir.singh, luca,
	christopher.squires, edwin, wayne.burri,
	Linux Kernel Mailing List

On Wed, Aug 12, 2015 at 3:36 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Aug 12, 2015 at 3:20 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> Does your objection still apply if we supplied our own implementations of a
>> handful of libgcc helpers?
>
> We already do that.
>
> Several architectures actually implement _udivdi3.
>
> However, do_div() is actually the much simpler/better interface.
>
> I don't think we have a single case in the kernel where we really want
> the full 64/64 division, and the 64/32->64 case really is
> fundamentally simpler.
>
> This whole "do_div is so complicated" thing is just BS.
>
> The thing that triggered Christoph to ask was a bug in the
> implementation of that *simpler*  interface. What makes you think that
> making people implement _udivdi3 would magically avoid all such bugs?
>

Nothing.

We could ask gcc to fix this, I suppose (add __udiv_64_over_32 or whatever).

--Andy

^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-12 22:39                             ` Andy Lutomirski
  0 siblings, 0 replies; 38+ messages in thread
From: Andy Lutomirski @ 2015-08-12 22:39 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Aug 12, 2015 at 3:36 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Aug 12, 2015 at 3:20 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> Does your objection still apply if we supplied our own implementations of a
>> handful of libgcc helpers?
>
> We already do that.
>
> Several architectures actually implement _udivdi3.
>
> However, do_div() is actually the much simpler/better interface.
>
> I don't think we have a single case in the kernel where we really want
> the full 64/64 division, and the 64/32->64 case really is
> fundamentally simpler.
>
> This whole "do_div is so complicated" thing is just BS.
>
> The thing that triggered Christoph to ask was a bug in the
> implementation of that *simpler*  interface. What makes you think that
> making people implement _udivdi3 would magically avoid all such bugs?
>

Nothing.

We could ask gcc to fix this, I suppose (add __udiv_64_over_32 or whatever).

--Andy

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12 22:20                         ` Andy Lutomirski
@ 2015-08-13  3:28                           ` Andrew Morton
  -1 siblings, 0 replies; 38+ messages in thread
From: Andrew Morton @ 2015-08-13  3:28 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Christoph Hellwig, katsuki.uwatoko,
	linux-arm-kernel, Dave Chinner, gangchen,
	Russell King - ARM Linux, karanvir.singh, luca,
	christopher.squires, edwin, wayne.burri,
	Linux Kernel Mailing List

On Wed, 12 Aug 2015 15:20:54 -0700 Andy Lutomirski <luto@kernel.org> wrote:

> On 08/12/2015 08:49 AM, Linus Torvalds wrote:
> > On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
> >>
> >> Maybe it's time to rely on gcc to handle 64 bit divisions now?
> >
> > Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> > a widening 32x32->64 multiplication can be simplified, it doesn't do
> > the same thing for a 64/32->64 division, and always calls __udivdi3
> > for it.
> >
> > Now, __udivdi3 does avoid the general nasty case by then testing the
> > upper 32 bits of the divisor against zero, so it's not entirely
> > disastrous. It's just ugly.
> >
> > But perhaps more importantly, I'm not at all sure libgcc is
> > kernel-safe. In particular, I'm not at all sure it *remains*
> > kernel-safe. Just as an example: can you guarantee that libgcc doesn't
> > implement integer division on some architecture by using the FP
> > hardware?
> >
> > There's been a few cases where not having libgcc saved us headaches. I
> > forget the exact details, but it was something like several years ago
> > that we had gcc start to generate some insane crap exception handling
> > for C code generation, and the fact that we didn't include libgcc was
> > what made us catch it because of the resulting link error.
> >
> > libgcc just isn't reliable in kernel space. I'm not opposed to some
> > random architecture using it (arch/tile does include "-lgcc" for
> > example), but I _do_ object to the notion that we say "let's use
> > libgcc in general".
> >
> > So no. I do not believe that the occasional pain of a few people who
> > do 64-bit divides incorrectly is a good enough argument to start using
> > libgcc.
> >
> 
> Does your objection still apply if we supplied our own implementations 
> of a handful of libgcc helpers?

It's not just a matter of "how fast is the divide".  The 32-bit build
error is supposed to prompt people to ask "did I really need to use 64
bits".

That *used* to work.  A bit.  But nowadays the errors are detected so
late that the fix (often by someone other than the original developer)
is to just slap a do_div() in there.

And as the build error no longer appears to be having the desired
effect, I too have been wondering if it's time to just give up and
implement __udivdi and friends.

Or maybe there's a way of breaking 64-bit builds instead ;)

^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-08-13  3:28                           ` Andrew Morton
  0 siblings, 0 replies; 38+ messages in thread
From: Andrew Morton @ 2015-08-13  3:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 12 Aug 2015 15:20:54 -0700 Andy Lutomirski <luto@kernel.org> wrote:

> On 08/12/2015 08:49 AM, Linus Torvalds wrote:
> > On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
> >>
> >> Maybe it's time to rely on gcc to handle 64 bit divisions now?
> >
> > Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> > a widening 32x32->64 multiplication can be simplified, it doesn't do
> > the same thing for a 64/32->64 division, and always calls __udivdi3
> > for it.
> >
> > Now, __udivdi3 does avoid the general nasty case by then testing the
> > upper 32 bits of the divisor against zero, so it's not entirely
> > disastrous. It's just ugly.
> >
> > But perhaps more importantly, I'm not at all sure libgcc is
> > kernel-safe. In particular, I'm not at all sure it *remains*
> > kernel-safe. Just as an example: can you guarantee that libgcc doesn't
> > implement integer division on some architecture by using the FP
> > hardware?
> >
> > There's been a few cases where not having libgcc saved us headaches. I
> > forget the exact details, but it was something like several years ago
> > that we had gcc start to generate some insane crap exception handling
> > for C code generation, and the fact that we didn't include libgcc was
> > what made us catch it because of the resulting link error.
> >
> > libgcc just isn't reliable in kernel space. I'm not opposed to some
> > random architecture using it (arch/tile does include "-lgcc" for
> > example), but I _do_ object to the notion that we say "let's use
> > libgcc in general".
> >
> > So no. I do not believe that the occasional pain of a few people who
> > do 64-bit divides incorrectly is a good enough argument to start using
> > libgcc.
> >
> 
> Does your objection still apply if we supplied our own implementations 
> of a handful of libgcc helpers?

It's not just a matter of "how fast is the divide".  The 32-bit build
error is supposed to prompt people to ask "did I really need to use 64
bits".

That *used* to work.  A bit.  But nowadays the errors are detected so
late that the fix (often by someone other than the original developer)
is to just slap a do_div() in there.

And as the build error no longer appears to be having the desired
effect, I too have been wondering if it's time to just give up and
implement __udivdi and friends.

Or maybe there's a way of breaking 64-bit builds instead ;)

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
  2015-08-12 15:49                       ` Linus Torvalds
@ 2015-10-08 15:50                         ` Pavel Machek
  -1 siblings, 0 replies; 38+ messages in thread
From: Pavel Machek @ 2015-10-08 15:50 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Christoph Hellwig, katsuki.uwatoko, linux-arm-kernel,
	Dave Chinner, gangchen, Russell King - ARM Linux, karanvir.singh,
	luca, christopher.squires, edwin, wayne.burri,
	Linux Kernel Mailing List

Hi!

On Wed 2015-08-12 08:49:45, Linus Torvalds wrote:
> On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > Maybe it's time to rely on gcc to handle 64 bit divisions now?
> 
> Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> a widening 32x32->64 multiplication can be simplified, it doesn't do
> the same thing for a 64/32->64 division, and always calls __udivdi3
> for it.
> 
> Now, __udivdi3 does avoid the general nasty case by then testing the
> upper 32 bits of the divisor against zero, so it's not entirely
> disastrous. It's just ugly.
> 
> But perhaps more importantly, I'm not at all sure libgcc is
> kernel-safe. In particular, I'm not at all sure it *remains*
> kernel-safe. Just as an example: can you guarantee that libgcc doesn't

U-Boot relies on toolchain-provided libgcc by default, and one of reasons
we do that is so that libgcc stays sane. Yes, there's occasionally some fun
with that.

But if kernel did that, at least U-Boot would not be alone with the fun.

									Pavel

^ permalink raw reply	[flat|nested] 38+ messages in thread

* enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
@ 2015-10-08 15:50                         ` Pavel Machek
  0 siblings, 0 replies; 38+ messages in thread
From: Pavel Machek @ 2015-10-08 15:50 UTC (permalink / raw)
  To: linux-arm-kernel

Hi!

On Wed 2015-08-12 08:49:45, Linus Torvalds wrote:
> On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > Maybe it's time to rely on gcc to handle 64 bit divisions now?
> 
> Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> a widening 32x32->64 multiplication can be simplified, it doesn't do
> the same thing for a 64/32->64 division, and always calls __udivdi3
> for it.
> 
> Now, __udivdi3 does avoid the general nasty case by then testing the
> upper 32 bits of the divisor against zero, so it's not entirely
> disastrous. It's just ugly.
> 
> But perhaps more importantly, I'm not at all sure libgcc is
> kernel-safe. In particular, I'm not at all sure it *remains*
> kernel-safe. Just as an example: can you guarantee that libgcc doesn't

U-Boot relies on toolchain-provided libgcc by default, and one of reasons
we do that is so that libgcc stays sane. Yes, there's occasionally some fun
with that.

But if kernel did that, at least U-Boot would not be alone with the fun.

									Pavel

^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2015-10-08 15:50 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-11  6:23 PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Török Edwin
2015-06-11 15:16 ` Brian Foster
2015-06-11 15:28   ` Török Edwin
2015-06-11 15:51     ` Eric Sandeen
2015-06-11 15:58       ` Eric Sandeen
2015-06-11 16:32         ` Török Edwin
2015-06-11 17:10           ` Eric Sandeen
2015-06-11 17:13             ` Török Edwin
2015-06-11 17:16               ` Eric Sandeen
2015-06-11 20:07           ` Eric Sandeen
2015-06-11 20:29             ` Eric Sandeen
2015-06-11 22:53             ` Dave Chinner
2015-06-12 12:21           ` Brian Foster
2015-06-12 12:47             ` Török Edwin
2015-06-12 13:54               ` Brian Foster
2015-06-12 20:19                 ` Eric Sandeen
     [not found]                   ` <BLUPR04MB593340A765596780F266454F2BB0@BLUPR04MB593.namprd04.prod.outlook.com>
2015-06-13 13:55                     ` Török Edwin
2015-06-12 22:52               ` Dave Chinner
2015-08-12  0:56                 ` katsuki.uwatoko
2015-08-12  0:56                   ` katsuki.uwatoko at toshiba.co.jp
2015-08-12  3:14                   ` Dave Chinner
2015-08-12  3:14                     ` Dave Chinner
2015-08-12  6:19                     ` katsuki.uwatoko
2015-08-12  6:19                       ` katsuki.uwatoko at toshiba.co.jp
2015-08-12  6:24                   ` enabling libgcc for 64-bit divisions, was " Christoph Hellwig
2015-08-12  6:24                     ` Christoph Hellwig
2015-08-12 15:49                     ` Linus Torvalds
2015-08-12 15:49                       ` Linus Torvalds
2015-08-12 22:20                       ` Andy Lutomirski
2015-08-12 22:20                         ` Andy Lutomirski
2015-08-12 22:36                         ` Linus Torvalds
2015-08-12 22:36                           ` Linus Torvalds
2015-08-12 22:39                           ` Andy Lutomirski
2015-08-12 22:39                             ` Andy Lutomirski
2015-08-13  3:28                         ` Andrew Morton
2015-08-13  3:28                           ` Andrew Morton
2015-10-08 15:50                       ` Pavel Machek
2015-10-08 15:50                         ` Pavel Machek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.