[announce] vfs-scale git tree update

[announce] vfs-scale git tree update

[Nick Piggin]

Git tree is here:

  git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git

Branch is:

    vfs-scale-working

Changes since last posting:
* Fix for the cgroupfs crash (probably temporary until Al's fixes are
  merged).
* Fix a couple of bisectability bugs.
* Fix a race in disconnected dentry alias handling causing NFS to explode
  under load. Basically the patch to split dentry hash locks needs to
  lock the s_anon list with a seperate lock, which it wasn't doing
  properly in the d_move() code.

Thanks to all testers.

Re: [announce] vfs-scale git tree update

[Sedat Dilek]

On Wed, Dec 22, 2010 at 10:53 AM, Nick Piggin <npiggin@kernel.dk> wrote:
> Git tree is here:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
>
> Branch is:
>
>    vfs-scale-working
>
> Changes since last posting:
> * Fix for the cgroupfs crash (probably temporary until Al's fixes are
>  merged).
> * Fix a couple of bisectability bugs.
> * Fix a race in disconnected dentry alias handling causing NFS to explode
>  under load. Basically the patch to split dentry hash locks needs to
>  lock the s_anon list with a seperate lock, which it wasn't doing
>  properly in the d_move() code.
>
> Thanks to all testers.
>

[ CC Al Viro and Lennart Poettering ]

Thanks for fixing this so quickly, Nick.
I am looking forward to see Al's vfs work got merged into linux-next.

Here some feedback from IRC #systemd/freenode (21-Dec-2010, UTC+1):

[17:14:23] <mezcaler1> dileks: fun that we are able to trigger such problems
[17:14:46] <mezcaler1> dileks: seems systemd is definitely a good
"test case" already ;-)


- Sedat -

Re: [announce] vfs-scale git tree update

[Sedat Dilek]

On Wed, Dec 22, 2010 at 10:53 AM, Nick Piggin <npiggin@kernel.dk> wrote:
> Git tree is here:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
>
> Branch is:
>
>    vfs-scale-working
>

Hmm, looks like the new commits were not committed to your remote GIT branch.
Just as a hint the EU mirror seems to work faster for GIT repos
(s/git.kernel.org/git.eu.kernel.org).

- Sedat -

P.S.:

$ git pull git://git.eu.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
vfs-scale-working:vfs-scale-working
Already up-to-date.

$ git log -1 | cat
commit 695394855fba70ce7e833e4742792e9a738af6b0
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Tue Dec 21 18:13:04 2010 +1100

    Add linux-next specific files for 20101221

    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[announce] vfs-scale git tree update

[Nick Piggin]

Git tree is here:
  
  git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
  
Branch is:

    vfs-scale-working

Changes since last posting:
* Updated to 2.6.37 (Documentation/filesystems/Locking clash)
* Switch names of vfsmount scalable counter helpers suggested by Andreas
* Most significant are changes in Documentation/filesystems/path-lookup.txt
  attempt to make it more readable, consistent and informative. Add some
  interesting rcu-walk path lookup success and behaviour statistics.

Status:
* Linus is planning to merge. It's never too late for review, though.
* linux-next has been uneventful, but I don't think it nearly covers all
  interesting and fiddly use cases.
* Still has the barrier-less __seqcount optimisation that Linus didn't
  like; I like the idea of a seqcount-switch API, but it just didn't
  seem to fit well here. Let's leave that on the todo list?

Future dcache / name lookup work:
* Per-zone LRUs. Patch is simple and ready, but performance bisecting
  might be a bit easier if we hold off. Also inode LRUs should be done at
  the same time.
* Filesystems will need to start implementing rcu-walk aware dentry
  and permission ops. They've got simple examples to follow.
* Rename scaling. The rename seqlock can explode on large systems,
  getting into strange conditions where lookup performance crashes.
  It is also a global lock for renames. Quite simple to break it up and
  fix lookup performance and provide linear vfs scalability for parallel
  same-directory renames (if they are in different directories). Doesn't
  need to be merged yet, though.
* Further optimise name string copying and comparison (may be as much as
  10-20% in that).
* rcu-walk for symlinks. A bit tricky, not impossible.

Re: [announce] vfs-scale git tree update

[Anca Emanuel]

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

On Wed, Jan 5, 2011 at 12:25 PM, Nick Piggin <npiggin@kernel.dk> wrote:
> Git tree is here:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
>
> Branch is:
>
>    vfs-scale-working

Working fine here !

Thanks Nick.

[-- Attachment #2: dmesg-vfs.txt --]
[-- Type: text/plain, Size: 55260 bytes --]

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.37-vfs+ (root@ubuntu) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #1 SMP Wed Jan 5 21:21:24 EET 2011
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000007ffb0000 (usable)
[    0.000000]  BIOS-e820: 000000007ffb0000 - 000000007ffbe000 (ACPI data)
[    0.000000]  BIOS-e820: 000000007ffbe000 - 000000007fff0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000007fff0000 - 0000000080000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
[    0.000000] DMI present.
[    0.000000] DMI: MS-7360/MS-7360, BIOS V1.10 11/11/2008
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x7ffb0 max_arch_pfn = 0x100000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-CFFFF write-protect
[    0.000000]   D0000-DFFFF uncachable
[    0.000000]   E0000-EFFFF write-through
[    0.000000]   F0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000 mask F80000000 write-back
[    0.000000]   1 disabled
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [c00ff780] ff780
[    0.000000] Scanning 0 areas for low memory corruption
[    0.000000] initial memory mapped : 0 - 00c00000
[    0.000000] init_memory_mapping: 0000000000000000-00000000377fe000
[    0.000000]  0000000000 - 0000400000 page 4k
[    0.000000]  0000400000 - 0037400000 page 2M
[    0.000000]  0037400000 - 00377fe000 page 4k
[    0.000000] kernel direct mapping tables up to 377fe000 @ bfb000-c00000
[    0.000000] RAMDISK: 37589000 - 37ff0000
[    0.000000] Allocated new RAMDISK: 36b22000 - 37588d8f
[    0.000000] Move RAMDISK from 0000000037589000 - 0000000037fefd8e to 36b22000 - 37588d8e
[    0.000000] ACPI: RSDP 000f9bb0 00014 (v00 ACPIAM)
[    0.000000] ACPI: RSDT 7ffb0000 00040 (v01 111108 RSDT0906 20081111 MSFT 00000097)
[    0.000000] ACPI: FACP 7ffb0200 00084 (v01 111108 FACP0906 20081111 MSFT 00000097)
[    0.000000] ACPI: DSDT 7ffb0440 05595 (v01  0AAAA 0AAAA000 00000000 INTL 20051117)
[    0.000000] ACPI: FACS 7ffbe000 00040
[    0.000000] ACPI: APIC 7ffb0390 0006C (v01 111108 APIC0906 20081111 MSFT 00000097)
[    0.000000] ACPI: MCFG 7ffb0400 0003C (v01 111108 OEMMCFG  20081111 MSFT 00000097)
[    0.000000] ACPI: OEMB 7ffbe040 00071 (v01 111108 OEMB0906 20081111 MSFT 00000097)
[    0.000000] ACPI: HPET 7ffb59e0 00038 (v01 111108 OEMHPET  20081111 MSFT 00000097)
[    0.000000] ACPI: GSCI 7ffbe0c0 02024 (v01 111108 GMCHSCI  20081111 MSFT 00000097)
[    0.000000] ACPI: SSDT 7ffc0570 00A7C (v01 DpgPmm    CpuPm 00000012 INTL 20051117)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] 1159MB HIGHMEM available.
[    0.000000] 887MB LOWMEM available.
[    0.000000]   mapped low ram: 0 - 377fe000
[    0.000000]   low ram: 0 - 377fe000
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   Normal   0x00001000 -> 0x000377fe
[    0.000000]   HighMem  0x000377fe -> 0x0007ffb0
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x0007ffb0
[    0.000000] On node 0 totalpages: 524095
[    0.000000] free_area_init_node: node 0, pgdat c0809c40, node_mem_map f5b22200
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3951 pages, LIFO batch:0
[    0.000000]   Normal zone: 1744 pages used for memmap
[    0.000000]   Normal zone: 221486 pages, LIFO batch:31
[    0.000000]   HighMem zone: 2320 pages used for memmap
[    0.000000]   HighMem zone: 294562 pages, LIFO batch:31
[    0.000000] Using APIC driver default
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0xffffffff base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 2 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e3000
[    0.000000] PM: Registered nosave memory: 00000000000e3000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 80000000 (gap: 80000000:7ee00000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 12 pages/cpu @f5400000 s28544 r0 d20608 u1048576
[    0.000000] pcpu-alloc: s28544 r0 d20608 u1048576 alloc=1*4194304
[    0.000000] pcpu-alloc: [0] 0 1 2 3 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 519999
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37-vfs+ root=UUID=d4578a46-8171-4c14-886f-0444e0b81032 ro quiet splash
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Initializing CPU#0
[    0.000000] allocated 10483840 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Initializing HighMem for node 0 (000377fe:0007ffb0)
[    0.000000] Memory: 2049164k/2096832k available (5001k kernel code, 47216k reserved, 2309k data, 684k init, 1187528k highmem)
[    0.000000] virtual kernel memory layout:
[    0.000000]     fixmap  : 0xfff16000 - 0xfffff000   ( 932 kB)
[    0.000000]     pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
[    0.000000]     vmalloc : 0xf7ffe000 - 0xff7fe000   ( 120 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf77fe000   ( 887 MB)
[    0.000000]       .init : 0xc0824000 - 0xc08cf000   ( 684 kB)
[    0.000000]       .data : 0xc05e27b6 - 0xc0823d48   (2309 kB)
[    0.000000]       .text : 0xc0100000 - 0xc05e27b6   (5001 kB)
[    0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] 	RCU-based detection of stalled CPUs is disabled.
[    0.000000] NR_IRQS:2304 nr_irqs:712 16
[    0.000000] CPU 0 irqstacks, hard=f4408000 soft=f440a000
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2000.844 MHz processor.
[    0.004005] Calibrating delay loop (skipped), value calculated using timer frequency.. 4001.68 BogoMIPS (lpj=8003376)
[    0.004010] pid_max: default: 32768 minimum: 301
[    0.004035] Security Framework initialized
[    0.004050] AppArmor: AppArmor initialized
[    0.004102] Mount-cache hash table entries: 512
[    0.004239] Initializing cgroup subsys ns
[    0.004243] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
[    0.004246] Initializing cgroup subsys cpuacct
[    0.004252] Initializing cgroup subsys memory
[    0.004261] Initializing cgroup subsys devices
[    0.004263] Initializing cgroup subsys freezer
[    0.004265] Initializing cgroup subsys net_cls
[    0.004297] CPU: Physical Processor ID: 0
[    0.004299] CPU: Processor Core ID: 0
[    0.004302] mce: CPU supports 6 MCE banks
[    0.004309] CPU0: Thermal monitoring enabled (TM2)
[    0.004313] using mwait in idle threads.
[    0.004319] Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
[    0.004325] PEBS disabled due to CPU errata.
[    0.004332] ... version:                2
[    0.004333] ... bit width:              40
[    0.004335] ... generic registers:      2
[    0.004337] ... value mask:             000000ffffffffff
[    0.004340] ... max period:             000000007fffffff
[    0.004342] ... fixed-purpose events:   3
[    0.004344] ... event mask:             0000000700000003
[    0.009729] ACPI: Core revision 20101013
[    0.017145] ftrace: allocating 20913 entries in 41 pages
[    0.020057] Enabling APIC mode:  Flat.  Using 1 I/O APICs
[    0.020365] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.062850] CPU0: Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz stepping 0d
[    0.064000] CPU 1 irqstacks, hard=f44b2000 soft=f44b4000
[    0.064000] Booting Node   0, Processors  #1
[    0.008000] Initializing CPU#1
[    0.152016] Brought up 2 CPUs
[    0.152019] Total of 2 processors activated (8003.01 BogoMIPS).
[    0.152419] devtmpfs: initialized
[    0.153157] regulator: core version 0.5
[    0.153206] regulator: dummy: 
[    0.153225] Time: 22:55:13  Date: 01/05/11
[    0.153269] NET: Registered protocol family 16
[    0.153395] EISA bus registered
[    0.153403] ACPI: bus type pci registered
[    0.153488] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.153491] PCI: not using MMCONFIG
[    0.153656] PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=5
[    0.153658] PCI: Using configuration type 1 for base access
[    0.154631] bio: create slab <bio-0> at 0
[    0.157186] ACPI: EC: Detected MSI hardware, enabling workarounds.
[    0.157190] ACPI: EC: Look up EC in DSDT
[    0.158943] ACPI: Executed 1 blocks of module-level executable AML code
[    0.163957] ACPI: SSDT 7ffc00f0 00235 (v01 DpgPmm  P001Ist 00000011 INTL 20051117)
[    0.164345] ACPI: Dynamic OEM Table Load:
[    0.164349] ACPI: SSDT   (null) 00235 (v01 DpgPmm  P001Ist 00000011 INTL 20051117)
[    0.164832] ACPI: SSDT 7ffc0330 00235 (v01 DpgPmm  P002Ist 00000012 INTL 20051117)
[    0.165209] ACPI: Dynamic OEM Table Load:
[    0.165213] ACPI: SSDT   (null) 00235 (v01 DpgPmm  P002Ist 00000012 INTL 20051117)
[    0.165565] ACPI: Interpreter enabled
[    0.165577] ACPI: (supports S0 S3 S4 S5)
[    0.165600] ACPI: Using IOAPIC for interrupt routing
[    0.165634] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.167356] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[    0.167359] PCI: Using MMCONFIG for extended config space
[    0.168186] ACPI Exception: AE_NOT_FOUND, Evaluating _PRW (20101013/scan-723)
[    0.168978] ACPI Exception: AE_NOT_FOUND, Evaluating _PRW (20101013/scan-723)
[    0.169134] ACPI Exception: AE_NOT_FOUND, Evaluating _PRW (20101013/scan-723)
[    0.175045] ACPI: No dock devices found.
[    0.175050] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.175339] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.175630] pci_root PNP0A08:00: host bridge window [io  0x0000-0x0cf7]
[    0.175633] pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]
[    0.175636] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.175639] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff]
[    0.175642] pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xdfffffff]
[    0.175645] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xffffffff]
[    0.175659] pci 0000:00:00.0: [8086:29c0] type 0 class 0x000600
[    0.175709] pci 0000:00:01.0: [8086:29c1] type 1 class 0x000604
[    0.175749] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    0.175753] pci 0000:00:01.0: PME# disabled
[    0.175796] pci 0000:00:1a.0: [8086:2937] type 0 class 0x000c03
[    0.175843] pci 0000:00:1a.0: reg 20: [io  0xbc00-0xbc1f]
[    0.175891] pci 0000:00:1a.1: [8086:2938] type 0 class 0x000c03
[    0.175938] pci 0000:00:1a.1: reg 20: [io  0xb880-0xb89f]
[    0.176007] pci 0000:00:1a.7: [8086:293c] type 0 class 0x000c03
[    0.176030] pci 0000:00:1a.7: reg 10: [mem 0xf9fffc00-0xf9ffffff]
[    0.176109] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    0.176114] pci 0000:00:1a.7: PME# disabled
[    0.176139] pci 0000:00:1b.0: [8086:293e] type 0 class 0x000403
[    0.176156] pci 0000:00:1b.0: reg 10: [mem 0xf9ff8000-0xf9ffbfff 64bit]
[    0.176216] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[    0.176220] pci 0000:00:1b.0: PME# disabled
[    0.176241] pci 0000:00:1c.0: [8086:2940] type 1 class 0x000604
[    0.176301] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.176306] pci 0000:00:1c.0: PME# disabled
[    0.176331] pci 0000:00:1c.4: [8086:2948] type 1 class 0x000604
[    0.176392] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    0.176396] pci 0000:00:1c.4: PME# disabled
[    0.176419] pci 0000:00:1c.5: [8086:294a] type 1 class 0x000604
[    0.176479] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    0.176483] pci 0000:00:1c.5: PME# disabled
[    0.176508] pci 0000:00:1d.0: [8086:2934] type 0 class 0x000c03
[    0.176555] pci 0000:00:1d.0: reg 20: [io  0xb800-0xb81f]
[    0.176603] pci 0000:00:1d.1: [8086:2935] type 0 class 0x000c03
[    0.176649] pci 0000:00:1d.1: reg 20: [io  0xb480-0xb49f]
[    0.176697] pci 0000:00:1d.2: [8086:2936] type 0 class 0x000c03
[    0.176744] pci 0000:00:1d.2: reg 20: [io  0xb400-0xb41f]
[    0.176791] pci 0000:00:1d.3: [8086:2939] type 0 class 0x000c03
[    0.176838] pci 0000:00:1d.3: reg 20: [io  0xb080-0xb09f]
[    0.176894] pci 0000:00:1d.7: [8086:293a] type 0 class 0x000c03
[    0.176917] pci 0000:00:1d.7: reg 10: [mem 0xf9fff800-0xf9fffbff]
[    0.176996] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    0.177001] pci 0000:00:1d.7: PME# disabled
[    0.177024] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604
[    0.177086] pci 0000:00:1f.0: [8086:2918] type 0 class 0x000601
[    0.177168] pci 0000:00:1f.0: quirk: [io  0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO
[    0.177172] pci 0000:00:1f.0: quirk: [io  0x0480-0x04bf] claimed by ICH6 GPIO
[    0.177176] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0a00 (mask 00ff)
[    0.177218] pci 0000:00:1f.2: [8086:2921] type 0 class 0x000101
[    0.177235] pci 0000:00:1f.2: reg 10: [io  0xb000-0xb007]
[    0.177244] pci 0000:00:1f.2: reg 14: [io  0xac00-0xac03]
[    0.177253] pci 0000:00:1f.2: reg 18: [io  0xa880-0xa887]
[    0.177262] pci 0000:00:1f.2: reg 1c: [io  0xa800-0xa803]
[    0.177272] pci 0000:00:1f.2: reg 20: [io  0xa480-0xa48f]
[    0.177281] pci 0000:00:1f.2: reg 24: [io  0xa400-0xa40f]
[    0.177321] pci 0000:00:1f.3: [8086:2930] type 0 class 0x000c05
[    0.177338] pci 0000:00:1f.3: reg 10: [mem 0xf9fff400-0xf9fff4ff 64bit]
[    0.177361] pci 0000:00:1f.3: reg 20: [io  0x0400-0x041f]
[    0.177397] pci 0000:00:1f.5: [8086:2926] type 0 class 0x000101
[    0.177414] pci 0000:00:1f.5: reg 10: [io  0xa000-0xa007]
[    0.177423] pci 0000:00:1f.5: reg 14: [io  0x9c00-0x9c03]
[    0.177432] pci 0000:00:1f.5: reg 18: [io  0x9880-0x9887]
[    0.177442] pci 0000:00:1f.5: reg 1c: [io  0x9800-0x9803]
[    0.177451] pci 0000:00:1f.5: reg 20: [io  0x9480-0x948f]
[    0.177460] pci 0000:00:1f.5: reg 24: [io  0x9400-0x940f]
[    0.177539] pci 0000:01:00.0: [10de:0611] type 0 class 0x000300
[    0.177551] pci 0000:01:00.0: reg 10: [mem 0xfd000000-0xfdffffff]
[    0.177564] pci 0000:01:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.177576] pci 0000:01:00.0: reg 1c: [mem 0xfa000000-0xfbffffff 64bit]
[    0.177586] pci 0000:01:00.0: reg 24: [io  0xcc00-0xcc7f]
[    0.177595] pci 0000:01:00.0: reg 30: [mem 0xfe9e0000-0xfe9fffff pref]
[    0.177643] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.177647] pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]
[    0.177651] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfe9fffff]
[    0.177656] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.177700] pci 0000:00:1c.0: PCI bridge to [bus 02-02]
[    0.177704] pci 0000:00:1c.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.177709] pci 0000:00:1c.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.177716] pci 0000:00:1c.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.177777] pci 0000:03:00.0: [11ab:6121] type 0 class 0x000101
[    0.177795] pci 0000:03:00.0: reg 10: [io  0xdc00-0xdc07]
[    0.177809] pci 0000:03:00.0: reg 14: [io  0xd880-0xd883]
[    0.177822] pci 0000:03:00.0: reg 18: [io  0xd800-0xd807]
[    0.177835] pci 0000:03:00.0: reg 1c: [io  0xd480-0xd483]
[    0.177848] pci 0000:03:00.0: reg 20: [io  0xd400-0xd40f]
[    0.177861] pci 0000:03:00.0: reg 24: [mem 0xfeaffc00-0xfeafffff]
[    0.177909] pci 0000:03:00.0: supports D1
[    0.177911] pci 0000:03:00.0: PME# supported from D0 D1 D3hot
[    0.177917] pci 0000:03:00.0: PME# disabled
[    0.177935] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    0.177945] pci 0000:00:1c.4: PCI bridge to [bus 03-03]
[    0.177950] pci 0000:00:1c.4:   bridge window [io  0xd000-0xdfff]
[    0.177954] pci 0000:00:1c.4:   bridge window [mem 0xfea00000-0xfeafffff]
[    0.177961] pci 0000:00:1c.4:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.178027] pci 0000:04:00.0: [10ec:8168] type 0 class 0x000200
[    0.178047] pci 0000:04:00.0: reg 10: [io  0xe800-0xe8ff]
[    0.178081] pci 0000:04:00.0: reg 18: [mem 0xfebff000-0xfebfffff 64bit]
[    0.178119] pci 0000:04:00.0: reg 30: [mem 0xfebc0000-0xfebdffff pref]
[    0.178169] pci 0000:04:00.0: supports D1 D2
[    0.178171] pci 0000:04:00.0: PME# supported from D1 D2 D3hot D3cold
[    0.178177] pci 0000:04:00.0: PME# disabled
[    0.178201] pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    0.178212] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    0.178216] pci 0000:00:1c.5:   bridge window [io  0xe000-0xefff]
[    0.178221] pci 0000:00:1c.5:   bridge window [mem 0xfeb00000-0xfebfffff]
[    0.178227] pci 0000:00:1c.5:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.178294] pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
[    0.178298] pci 0000:00:1e.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.178303] pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.178310] pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.178313] pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
[    0.178316] pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    0.178319] pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    0.178325] pci 0000:00:1e.0:   bridge window [mem 0x000d0000-0x000dffff] (subtractive decode)
[    0.178328] pci 0000:00:1e.0:   bridge window [mem 0x80000000-0xdfffffff] (subtractive decode)
[    0.178331] pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xffffffff] (subtractive decode)
[    0.178353] pci_bus 0000:00: on NUMA node 0
[    0.178357] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.178549] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
[    0.178691] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
[    0.178760] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT]
[    0.178816] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P9._PRT]
[    0.190290] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12 14 15)
[    0.190359] ACPI: PCI Interrupt Link [LNKB] (IRQs *5)
[    0.190420] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 *14 15)
[    0.190486] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12 14 15)
[    0.190551] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.
[    0.190618] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12 14 *15)
[    0.190685] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 6 7 10 11 12 14 15)
[    0.190751] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 *7 10 11 12 14 15)
[    0.190786] HEST: Table is not found!
[    0.190878] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.190883] vgaarb: loaded
[    0.191051] SCSI subsystem initialized
[    0.191066] libata version 3.00 loaded.
[    0.191066] usbcore: registered new interface driver usbfs
[    0.191066] usbcore: registered new interface driver hub
[    0.191066] usbcore: registered new device driver usb
[    0.191066] wmi: Mapper loaded
[    0.191066] PCI: Using ACPI for IRQ routing
[    0.191066] PCI: pci_cache_line_size set to 64 bytes
[    0.191066] reserve RAM buffer: 000000000009f800 - 000000000009ffff 
[    0.191066] reserve RAM buffer: 000000007ffb0000 - 000000007fffffff 
[    0.191066] NetLabel: Initializing
[    0.191066] NetLabel:  domain hash size = 128
[    0.191066] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.191066] NetLabel:  unlabeled traffic allowed by default
[    0.191066] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[    0.191066] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    0.191066] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[    0.196021] Switching to clocksource tsc
[    0.204563] AppArmor: AppArmor Filesystem Enabled
[    0.204582] pnp: PnP ACPI init
[    0.204610] ACPI: bus type pnp registered
[    0.204788] pnp 00:00: [bus 00-ff]
[    0.204792] pnp 00:00: [io  0x0cf8-0x0cff]
[    0.204795] pnp 00:00: [io  0x0000-0x0cf7 window]
[    0.204798] pnp 00:00: [io  0x0d00-0xffff window]
[    0.204800] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    0.204803] pnp 00:00: [mem 0x000d0000-0x000dffff window]
[    0.204806] pnp 00:00: [mem 0x80000000-0xdfffffff window]
[    0.204808] pnp 00:00: [mem 0xf0000000-0xffffffff window]
[    0.204891] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)
[    0.204903] pnp 00:01: [mem 0xfed14000-0xfed19fff]
[    0.204964] pnp 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.205005] pnp 00:02: [dma 4]
[    0.205008] pnp 00:02: [io  0x0000-0x000f]
[    0.205011] pnp 00:02: [io  0x0081-0x0083]
[    0.205013] pnp 00:02: [io  0x0087]
[    0.205015] pnp 00:02: [io  0x0089-0x008b]
[    0.205017] pnp 00:02: [io  0x008f]
[    0.205020] pnp 00:02: [io  0x00c0-0x00df]
[    0.205056] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.205070] pnp 00:03: [io  0x0070-0x0071]
[    0.205083] pnp 00:03: [irq 8]
[    0.205116] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.205127] pnp 00:04: [io  0x0061]
[    0.205160] pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.205170] pnp 00:05: [io  0x00f0-0x00ff]
[    0.205176] pnp 00:05: [irq 13]
[    0.205210] pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)
[    0.205563] pnp 00:06: [io  0x03f8-0x03ff]
[    0.205570] pnp 00:06: [irq 4]
[    0.205572] pnp 00:06: [dma 0 disabled]
[    0.205649] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.205988] pnp 00:07: [io  0x0060]
[    0.205991] pnp 00:07: [io  0x0064]
[    0.205997] pnp 00:07: [irq 1]
[    0.206035] pnp 00:07: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    0.206095] pnp 00:08: [irq 12]
[    0.206133] pnp 00:08: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 (active)
[    0.206286] pnp 00:09: [io  0x0000-0xffffffff disabled]
[    0.206289] pnp 00:09: [io  0x0a00-0x0adf]
[    0.206292] pnp 00:09: [io  0x0ae0-0x0aef]
[    0.206353] pnp 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.206485] pnp 00:0a: [io  0x0010-0x001f]
[    0.206488] pnp 00:0a: [io  0x0022-0x003f]
[    0.206490] pnp 00:0a: [io  0x0044-0x005f]
[    0.206492] pnp 00:0a: [io  0x0062-0x0063]
[    0.206495] pnp 00:0a: [io  0x0065-0x006f]
[    0.206497] pnp 00:0a: [io  0x0072-0x007f]
[    0.206499] pnp 00:0a: [io  0x0080]
[    0.206502] pnp 00:0a: [io  0x0084-0x0086]
[    0.206504] pnp 00:0a: [io  0x0088]
[    0.206506] pnp 00:0a: [io  0x008c-0x008e]
[    0.206509] pnp 00:0a: [io  0x0090-0x009f]
[    0.206511] pnp 00:0a: [io  0x00a2-0x00bf]
[    0.206513] pnp 00:0a: [io  0x00e0-0x00ef]
[    0.206516] pnp 00:0a: [io  0x04d0-0x04d1]
[    0.206520] pnp 00:0a: [io  0x0800-0x087f]
[    0.206523] pnp 00:0a: [io  0x0000-0xffffffff disabled]
[    0.206526] pnp 00:0a: [io  0x0480-0x04bf]
[    0.206528] pnp 00:0a: [mem 0xfed1c000-0xfed1ffff]
[    0.206531] pnp 00:0a: [mem 0xfed20000-0xfed8ffff]
[    0.206614] pnp 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.206695] pnp 00:0b: [mem 0xfed00000-0xfed003ff]
[    0.206733] pnp 00:0b: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.206809] pnp 00:0c: [mem 0xffb00000-0xffbfffff]
[    0.206811] pnp 00:0c: [mem 0xfff00000-0xffffffff]
[    0.206851] pnp 00:0c: Plug and Play ACPI device, IDs INT0800 (active)
[    0.206928] pnp 00:0d: [mem 0xffc00000-0xffefffff]
[    0.206986] pnp 00:0d: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.207126] pnp 00:0e: [mem 0xfec00000-0xfec00fff]
[    0.207129] pnp 00:0e: [mem 0xfee00000-0xfee00fff]
[    0.207188] pnp 00:0e: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.207242] pnp 00:0f: [mem 0xe0000000-0xefffffff]
[    0.207301] pnp 00:0f: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.207572] pnp 00:10: [mem 0x00000000-0x0009ffff]
[    0.207575] pnp 00:10: [mem 0x000c0000-0x000cffff]
[    0.207577] pnp 00:10: [mem 0x000e0000-0x000fffff]
[    0.207580] pnp 00:10: [mem 0x00100000-0x7fffffff]
[    0.207583] pnp 00:10: [mem 0x00000000-0xffffffff disabled]
[    0.207657] pnp 00:10: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.207847] pnp: PnP ACPI: found 17 devices
[    0.207849] ACPI: ACPI bus type pnp unregistered
[    0.207853] PnPBIOS: Disabled by ACPI PNP
[    0.207866] system 00:01: [mem 0xfed14000-0xfed19fff] has been reserved
[    0.207876] system 00:09: [io  0x0a00-0x0adf] has been reserved
[    0.207879] system 00:09: [io  0x0ae0-0x0aef] has been reserved
[    0.207885] system 00:0a: [io  0x04d0-0x04d1] has been reserved
[    0.207888] system 00:0a: [io  0x0800-0x087f] has been reserved
[    0.207891] system 00:0a: [io  0x0480-0x04bf] has been reserved
[    0.207895] system 00:0a: [mem 0xfed1c000-0xfed1ffff] has been reserved
[    0.207898] system 00:0a: [mem 0xfed20000-0xfed8ffff] has been reserved
[    0.207904] system 00:0d: [mem 0xffc00000-0xffefffff] has been reserved
[    0.207910] system 00:0e: [mem 0xfec00000-0xfec00fff] could not be reserved
[    0.207914] system 00:0e: [mem 0xfee00000-0xfee00fff] has been reserved
[    0.207919] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserved
[    0.207926] system 00:10: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.207929] system 00:10: [mem 0x000c0000-0x000cffff] could not be reserved
[    0.207932] system 00:10: [mem 0x000e0000-0x000fffff] could not be reserved
[    0.207935] system 00:10: [mem 0x00100000-0x7fffffff] could not be reserved
[    0.244597] pci 0000:00:1c.0: BAR 14: assigned [mem 0x80000000-0x801fffff]
[    0.244602] pci 0000:00:1c.0: BAR 15: assigned [mem 0x80200000-0x803fffff 64bit pref]
[    0.244606] pci 0000:00:1c.4: BAR 15: assigned [mem 0x80400000-0x805fffff 64bit pref]
[    0.244610] pci 0000:00:1c.5: BAR 15: assigned [mem 0x80600000-0x807fffff 64bit pref]
[    0.244614] pci 0000:00:1c.0: BAR 13: assigned [io  0x1000-0x1fff]
[    0.244617] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.244620] pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]
[    0.244625] pci 0000:00:01.0:   bridge window [mem 0xfa000000-0xfe9fffff]
[    0.244629] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.244634] pci 0000:00:1c.0: PCI bridge to [bus 02-02]
[    0.244638] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    0.244643] pci 0000:00:1c.0:   bridge window [mem 0x80000000-0x801fffff]
[    0.244648] pci 0000:00:1c.0:   bridge window [mem 0x80200000-0x803fffff 64bit pref]
[    0.244655] pci 0000:00:1c.4: PCI bridge to [bus 03-03]
[    0.244658] pci 0000:00:1c.4:   bridge window [io  0xd000-0xdfff]
[    0.244663] pci 0000:00:1c.4:   bridge window [mem 0xfea00000-0xfeafffff]
[    0.244668] pci 0000:00:1c.4:   bridge window [mem 0x80400000-0x805fffff 64bit pref]
[    0.244675] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[    0.244678] pci 0000:00:1c.5:   bridge window [io  0xe000-0xefff]
[    0.244684] pci 0000:00:1c.5:   bridge window [mem 0xfeb00000-0xfebfffff]
[    0.244688] pci 0000:00:1c.5:   bridge window [mem 0x80600000-0x807fffff 64bit pref]
[    0.244695] pci 0000:00:1e.0: PCI bridge to [bus 05-05]
[    0.244697] pci 0000:00:1e.0:   bridge window [io  disabled]
[    0.244702] pci 0000:00:1e.0:   bridge window [mem disabled]
[    0.244706] pci 0000:00:1e.0:   bridge window [mem pref disabled]
[    0.244724] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.244729] pci 0000:00:01.0: setting latency timer to 64
[    0.244735] pci 0000:00:1c.0: enabling device (0104 -> 0107)
[    0.244742] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    0.244746] pci 0000:00:1c.0: setting latency timer to 64
[    0.244753] pci 0000:00:1c.4: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    0.244757] pci 0000:00:1c.4: setting latency timer to 64
[    0.244764] pci 0000:00:1c.5: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[    0.244769] pci 0000:00:1c.5: setting latency timer to 64
[    0.244776] pci 0000:00:1e.0: setting latency timer to 64
[    0.244780] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.244783] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.244786] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.244789] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff]
[    0.244792] pci_bus 0000:00: resource 8 [mem 0x80000000-0xdfffffff]
[    0.244795] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xffffffff]
[    0.244797] pci_bus 0000:01: resource 0 [io  0xc000-0xcfff]
[    0.244800] pci_bus 0000:01: resource 1 [mem 0xfa000000-0xfe9fffff]
[    0.244803] pci_bus 0000:01: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.244806] pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
[    0.244809] pci_bus 0000:02: resource 1 [mem 0x80000000-0x801fffff]
[    0.244811] pci_bus 0000:02: resource 2 [mem 0x80200000-0x803fffff 64bit pref]
[    0.244814] pci_bus 0000:03: resource 0 [io  0xd000-0xdfff]
[    0.244817] pci_bus 0000:03: resource 1 [mem 0xfea00000-0xfeafffff]
[    0.244820] pci_bus 0000:03: resource 2 [mem 0x80400000-0x805fffff 64bit pref]
[    0.244823] pci_bus 0000:04: resource 0 [io  0xe000-0xefff]
[    0.244825] pci_bus 0000:04: resource 1 [mem 0xfeb00000-0xfebfffff]
[    0.244828] pci_bus 0000:04: resource 2 [mem 0x80600000-0x807fffff 64bit pref]
[    0.244831] pci_bus 0000:05: resource 4 [io  0x0000-0x0cf7]
[    0.244834] pci_bus 0000:05: resource 5 [io  0x0d00-0xffff]
[    0.244836] pci_bus 0000:05: resource 6 [mem 0x000a0000-0x000bffff]
[    0.244839] pci_bus 0000:05: resource 7 [mem 0x000d0000-0x000dffff]
[    0.244842] pci_bus 0000:05: resource 8 [mem 0x80000000-0xdfffffff]
[    0.244844] pci_bus 0000:05: resource 9 [mem 0xf0000000-0xffffffff]
[    0.244884] NET: Registered protocol family 2
[    0.244965] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.245222] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.245612] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
[    0.245857] TCP: Hash tables configured (established 131072 bind 65536)
[    0.245860] TCP reno registered
[    0.245864] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.245874] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.245997] NET: Registered protocol family 1
[    0.246183] pci 0000:01:00.0: Boot video device
[    0.246193] PCI: CLS 32 bytes, default 64
[    0.246261] Trying to unpack rootfs image as initramfs...
[    0.518473] Freeing initrd memory: 10652k freed
[    0.523542] cpufreq-nforce2: No nForce2 chipset.
[    0.523580] Scanning for low memory corruption every 60 seconds
[    0.523716] audit: initializing netlink socket (disabled)
[    0.523730] type=2000 audit(1294268113.516:1): initialized
[    0.534843] highmem bounce pool size: 64 pages
[    0.534848] HugeTLB registered 4 MB page size, pre-allocated 0 pages
[    0.536849] VFS: Disk quotas dquot_6.5.2
[    0.536920] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.537669] fuse init (API version 7.15)
[    0.537777] msgmni has been set to 1703
[    0.538007] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.538010] io scheduler noop registered
[    0.538012] io scheduler deadline registered
[    0.538028] io scheduler cfq registered (default)
[    0.538449] pcieport 0000:00:01.0: ACPI _OSC control granted for 0x1d
[    0.538462] pcieport 0000:00:01.0: setting latency timer to 64
[    0.538497] pcieport 0000:00:01.0: irq 40 for MSI/MSI-X
[    0.538572] pcieport 0000:00:1c.0: ACPI _OSC control granted for 0x1d
[    0.538587] pcieport 0000:00:1c.0: setting latency timer to 64
[    0.538625] pcieport 0000:00:1c.0: irq 41 for MSI/MSI-X
[    0.538725] pcieport 0000:00:1c.4: ACPI _OSC control granted for 0x1d
[    0.538739] pcieport 0000:00:1c.4: setting latency timer to 64
[    0.538777] pcieport 0000:00:1c.4: irq 42 for MSI/MSI-X
[    0.538876] pcieport 0000:00:1c.5: ACPI _OSC control granted for 0x1d
[    0.538890] pcieport 0000:00:1c.5: setting latency timer to 64
[    0.538928] pcieport 0000:00:1c.5: irq 43 for MSI/MSI-X
[    0.539060] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[    0.539063] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    0.539067] pcie_pme 0000:00:01.0:pcie01: service driver pcie_pme loaded
[    0.539087] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[    0.539091] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded
[    0.539110] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt
[    0.539113] pci 0000:03:00.0: Signaling PME through PCIe PME interrupt
[    0.539118] pcie_pme 0000:00:1c.4:pcie01: service driver pcie_pme loaded
[    0.539137] pcieport 0000:00:1c.5: Signaling PME through PCIe PME interrupt
[    0.539139] pci 0000:04:00.0: Signaling PME through PCIe PME interrupt
[    0.539144] pcie_pme 0000:00:1c.5:pcie01: service driver pcie_pme loaded
[    0.539166] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.539219] pciehp 0000:00:1c.0:pcie04: HPC vendor_id 8086 device_id 2940 ss_vid 1462 ss_did 7360
[    0.539240] pciehp 0000:00:1c.0:pcie04: service driver pciehp loaded
[    0.539252] pciehp 0000:00:1c.4:pcie04: HPC vendor_id 8086 device_id 2948 ss_vid 1462 ss_did 7360
[    0.539272] pciehp 0000:00:1c.4:pcie04: service driver pciehp loaded
[    0.539284] pciehp 0000:00:1c.5:pcie04: HPC vendor_id 8086 device_id 294a ss_vid 1462 ss_did 7360
[    0.539306] pciehp 0000:00:1c.5:pcie04: service driver pciehp loaded
[    0.539315] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    0.539449] intel_idle: MWAIT substates: 0x220
[    0.539452] intel_idle: does not run on family 6 model 15
[    0.539562] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[    0.539568] ACPI: Power Button [PWRB]
[    0.539620] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    0.539624] ACPI: Power Button [PWRF]
[    0.539828] ACPI: acpi_idle registered with cpuidle
[    0.542039] ERST: Table is not found!
[    0.542098] isapnp: Scanning for PnP cards...
[    0.895119] isapnp: No Plug & Play device found
[    0.895313] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.915672] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.000250] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.021405] brd: module loaded
[    1.022103] loop: module loaded
[    1.022310] ata_piix 0000:00:1f.2: version 2.13
[    1.022332] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    1.022338] ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
[    1.022381] ata_piix 0000:00:1f.2: setting latency timer to 64
[    1.022683] scsi0 : ata_piix
[    1.022782] scsi1 : ata_piix
[    1.024531] ata1: SATA max UDMA/133 cmd 0xb000 ctl 0xac00 bmdma 0xa480 irq 19
[    1.024536] ata2: SATA max UDMA/133 cmd 0xa880 ctl 0xa800 bmdma 0xa488 irq 19
[    1.024561] ata_piix 0000:00:1f.5: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    1.024566] ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]
[    1.024610] ata_piix 0000:00:1f.5: setting latency timer to 64
[    1.024866] scsi2 : ata_piix
[    1.024942] scsi3 : ata_piix
[    1.026367] ata3: SATA max UDMA/133 cmd 0xa000 ctl 0x9c00 bmdma 0x9480 irq 19
[    1.026371] ata4: SATA max UDMA/133 cmd 0x9880 ctl 0x9800 bmdma 0x9488 irq 19
[    1.026426] pata_acpi 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    1.026457] pata_acpi 0000:03:00.0: setting latency timer to 64
[    1.026471] pata_acpi 0000:03:00.0: PCI INT A disabled
[    1.026848] Fixed MDIO Bus: probed
[    1.026885] PPP generic driver version 2.4.2
[    1.026945] tun: Universal TUN/TAP device driver, 1.6
[    1.026948] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.027054] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.027077] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    1.027093] ehci_hcd 0000:00:1a.7: setting latency timer to 64
[    1.027097] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[    1.027141] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[    1.039777] ehci_hcd 0000:00:1a.7: debug port 1
[    1.043651] ehci_hcd 0000:00:1a.7: cache line size of 32 is not supported
[    1.043669] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xf9fffc00
[    1.056007] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[    1.056144] hub 1-0:1.0: USB hub found
[    1.056149] hub 1-0:1.0: 4 ports detected
[    1.056249] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    1.056260] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[    1.056264] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[    1.056305] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[    1.056347] ehci_hcd 0000:00:1d.7: debug port 1
[    1.060226] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
[    1.060242] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf9fff800
[    1.076010] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    1.076137] hub 2-0:1.0: USB hub found
[    1.076142] hub 2-0:1.0: 8 ports detected
[    1.076237] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.076253] uhci_hcd: USB Universal Host Controller Interface driver
[    1.076288] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    1.076295] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[    1.076299] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[    1.076343] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[    1.076393] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000bc00
[    1.076533] hub 3-0:1.0: USB hub found
[    1.076538] hub 3-0:1.0: 2 ports detected
[    1.076621] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
[    1.076628] uhci_hcd 0000:00:1a.1: setting latency timer to 64
[    1.076631] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[    1.076676] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[    1.076722] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000b880
[    1.076857] hub 4-0:1.0: USB hub found
[    1.076862] hub 4-0:1.0: 2 ports detected
[    1.076943] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    1.076950] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[    1.076953] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    1.076997] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
[    1.080034] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000b800
[    1.080173] hub 5-0:1.0: USB hub found
[    1.080177] hub 5-0:1.0: 2 ports detected
[    1.080259] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    1.080266] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[    1.080269] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    1.080312] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
[    1.080348] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000b480
[    1.080484] hub 6-0:1.0: USB hub found
[    1.080488] hub 6-0:1.0: 2 ports detected
[    1.080569] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    1.080576] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[    1.080579] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    1.080622] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
[    1.080659] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000b400
[    1.080797] hub 7-0:1.0: USB hub found
[    1.080801] hub 7-0:1.0: 2 ports detected
[    1.080880] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    1.080886] uhci_hcd 0000:00:1d.3: setting latency timer to 64
[    1.080889] uhci_hcd 0000:00:1d.3: UHCI Host Controller
[    1.080938] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 8
[    1.080975] uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000b080
[    1.081116] hub 8-0:1.0: USB hub found
[    1.081121] hub 8-0:1.0: 2 ports detected
[    1.081301] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
[    1.083643] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.083649] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.083735] mice: PS/2 mouse device common for all mice
[    1.083873] rtc_cmos 00:03: RTC can wake from S4
[    1.083937] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[    1.083961] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    1.084101] device-mapper: uevent: version 1.0.3
[    1.084235] device-mapper: ioctl: 4.18.0-ioctl (2010-06-29) initialised: dm-devel@redhat.com
[    1.084292] device-mapper: multipath: version 1.1.1 loaded
[    1.084295] device-mapper: multipath round-robin: version 1.0.0 loaded
[    1.084432] EISA: Probing bus 0 at eisa.0
[    1.084435] EISA: Cannot allocate resource for mainboard
[    1.084438] Cannot allocate resource for EISA slot 1
[    1.084440] Cannot allocate resource for EISA slot 2
[    1.084442] Cannot allocate resource for EISA slot 3
[    1.084444] Cannot allocate resource for EISA slot 4
[    1.084446] Cannot allocate resource for EISA slot 5
[    1.084449] Cannot allocate resource for EISA slot 6
[    1.084451] Cannot allocate resource for EISA slot 7
[    1.084453] Cannot allocate resource for EISA slot 8
[    1.084455] EISA: Detected 0 cards.
[    1.084507] cpuidle: using governor ladder
[    1.084510] cpuidle: using governor menu
[    1.084853] TCP cubic registered
[    1.085001] NET: Registered protocol family 10
[    1.085425] lo: Disabled Privacy Extensions
[    1.085686] NET: Registered protocol family 17
[    1.085706] Registering the dns_resolver key type
[    1.086242] Using IPI No-Shortcut mode
[    1.086351] PM: Hibernation image not present or could not be loaded.
[    1.086363] registered taskstats version 1
[    1.086700]   Magic number: 11:568:956
[    1.086778] rtc_cmos 00:03: setting system clock to 2011-01-05 22:55:14 UTC (1294268114)
[    1.086782] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[    1.086784] EDD information not available.
[    1.107290] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    1.322614] ata4: SATA link down (SStatus 0 SControl 300)
[    1.333248] ata3: SATA link down (SStatus 0 SControl 300)
[    1.476042] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.476195] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.484248] ata2.00: ATAPI: PIONEER DVD-RW  DVR-212D, 1.24, max UDMA/66
[    1.484313] ata1.00: ATA-7: SAMSUNG HD103UJ, 1AA01113, max UDMA7
[    1.484316] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[    1.492274] ata1.00: configured for UDMA/133
[    1.492401] scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HD103UJ  1AA0 PQ: 0 ANSI: 5
[    1.492572] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    1.492586] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    1.492632] sd 0:0:0:0: [sda] Write Protect is off
[    1.492635] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.492666] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.500118] ata2.00: configured for UDMA/66
[    1.506053] scsi 1:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-212D 1.24 PQ: 0 ANSI: 5
[    1.529669] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
[    1.529672] cdrom: Uniform CD-ROM driver Revision: 3.20
[    1.529786] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    1.529850] sr 1:0:0:0: Attached scsi generic sg1 type 5
[    1.550782]  sda: sda1 sda2 < sda5 sda6 >
[    1.551122] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.551139] Freeing unused kernel memory: 684k freed
[    1.551486] Write protecting the kernel text: 5004k
[    1.551538] Write protecting the kernel read-only data: 1964k
[    1.570461] udev[74]: starting version 163
[    1.689054] ahci 0000:03:00.0: version 3.0
[    1.690546] pata_marvell 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    1.690584] pata_marvell 0000:03:00.0: setting latency timer to 64
[    1.692478] scsi4 : pata_marvell
[    1.692597] scsi5 : pata_marvell
[    1.692656] ata5: PATA max UDMA/100 cmd 0xdc00 ctl 0xd880 bmdma 0xd400 irq 16
[    1.692660] ata6: PATA max UDMA/133 cmd 0xd800 ctl 0xd480 bmdma 0xd408 irq 16
[    1.697278] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.697302] r8169 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    1.697350] r8169 0000:04:00.0: setting latency timer to 64
[    1.697424] r8169 0000:04:00.0: irq 44 for MSI/MSI-X
[    1.698023] r8169 0000:04:00.0: eth0: RTL8168b/8111b at 0xf8082000, 00:1d:92:33:07:c1, XID 18000000 IRQ 44
[    1.921590] EXT4-fs (sda5): INFO: recovery required on readonly filesystem
[    1.921596] EXT4-fs (sda5): write access will be enabled during recovery
[    5.335856] EXT4-fs (sda5): recovery complete
[    5.336325] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[   17.765943] udev[287]: starting version 163
[   17.816154] Adding 6037500k swap on /dev/sda6.  Priority:-1 extents:1 across:6037500k 
[   18.413930] lp: driver loaded but no devices found
[   18.462474] type=1400 audit(1294260931.873:2): apparmor="STATUS" operation="profile_load" name="/sbin/dhclient3" pid=503 comm="apparmor_parser"
[   18.462540] type=1400 audit(1294260931.873:3): apparmor="STATUS" operation="profile_load" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=503 comm="apparmor_parser"
[   18.462594] type=1400 audit(1294260931.873:4): apparmor="STATUS" operation="profile_load" name="/usr/lib/connman/scripts/dhclient-script" pid=503 comm="apparmor_parser"
[   18.522117] Linux agpgart interface v0.103
[   18.553152] type=1400 audit(1294260931.965:5): apparmor="STATUS" operation="profile_load" name="/usr/sbin/ntpd" pid=614 comm="apparmor_parser"
[   18.621835] [drm] Initialized drm 1.1.0 20060810
[   18.634691] psmouse serio1: ID: 10 00 64
[   18.833553] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
[   18.866215] nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   18.866223] nouveau 0000:01:00.0: setting latency timer to 64
[   18.868798] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x092880a2)
[   18.872277] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN
[   18.928111] [drm] nouveau 0000:01:00.0: ... appears to be valid
[   18.928116] [drm] nouveau 0000:01:00.0: BIT BIOS found
[   18.928120] [drm] nouveau 0000:01:00.0: Bios version 62.92.1f.00
[   18.928124] [drm] nouveau 0000:01:00.0: TMDS table version 2.0
[   18.928127] [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0
[   18.928130] [drm] nouveau 0000:01:00.0: Raw DCB entry 0: 02000300 00000028
[   18.928134] [drm] nouveau 0000:01:00.0: Raw DCB entry 1: 01000302 00000030
[   18.928137] [drm] nouveau 0000:01:00.0: Raw DCB entry 2: 04011310 00000028
[   18.928139] [drm] nouveau 0000:01:00.0: Raw DCB entry 3: 02011312 00000030
[   18.928142] [drm] nouveau 0000:01:00.0: Raw DCB entry 4: 010223f1 00c0c080
[   18.928145] [drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 16 4
[   18.928149] [drm] nouveau 0000:01:00.0:   0: 0x00001030: type 0x30 idx 0 tag 0x07
[   18.928152] [drm] nouveau 0000:01:00.0:   1: 0x00002130: type 0x30 idx 1 tag 0x08
[   18.928155] [drm] nouveau 0000:01:00.0:   2: 0x00000210: type 0x10 idx 2 tag 0xff
[   18.928158] [drm] nouveau 0000:01:00.0:   3: 0x00000211: type 0x11 idx 3 tag 0xff
[   18.928161] [drm] nouveau 0000:01:00.0:   4: 0x00000213: type 0x13 idx 4 tag 0xff
[   18.928166] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xC10F
[   18.972249] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xC4B3
[   18.988055] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xD22E
[   18.988066] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xD350
[   18.996113] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xD580
[   18.996118] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xD5E5
[   19.010095] r8169 0000:04:00.0: eth0: link up
[   19.010103] r8169 0000:04:00.0: eth0: link up
[   19.020123] [drm] nouveau 0000:01:00.0: 0xD5E5: Condition still not met after 20ms, skipping following opcodes
[   19.118461] type=1400 audit(1294260932.529:6): apparmor="STATUS" operation="profile_load" name="/usr/share/gdm/guest-session/Xsession" pid=724 comm="apparmor_parser"
[   19.186039] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input3
[   19.227019] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[   19.227073] HDA Intel 0000:00:1b.0: irq 45 for MSI/MSI-X
[   19.227100] HDA Intel 0000:00:1b.0: setting latency timer to 64
[   19.248051] adt7475 0-002e: ADT7473 device, revision 1
[   19.259294] [drm] nouveau 0000:01:00.0: Detected monitoring device: adt7473
[   19.259302] [drm] nouveau 0000:01:00.0: 1 available performance level(s)
[   19.259307] [drm] nouveau 0000:01:00.0: 3: memory 900MHz core 600MHz shader 1500MHz fanspeed 100%
[   19.259323] [drm] nouveau 0000:01:00.0: c: memory 399MHz core 399MHz shader 810MHz voltage 1050mV
[   19.268049] [drm] nouveau 0000:01:00.0: Detected 512MiB VRAM
[   19.276052] [TTM] Zone  kernel: Available graphics memory: 436486 kiB.
[   19.276056] [TTM] Zone highmem: Available graphics memory: 1030250 kiB.
[   19.276058] [TTM] Initializing pool allocator.
[   19.295304] hda_codec: ALC888: BIOS auto-probing.
[   19.300514] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input4
[   19.320089] [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture)
[   19.325192] type=1400 audit(1294260932.737:7): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient3" pid=725 comm="apparmor_parser"
[   19.325268] type=1400 audit(1294260932.737:8): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=725 comm="apparmor_parser"
[   19.325327] type=1400 audit(1294260932.737:9): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=725 comm="apparmor_parser"
[   19.330988] [drm] nouveau 0000:01:00.0: DCB encoder 1 unknown
[   19.330992] [drm] nouveau 0000:01:00.0: TV-1 has no encoders, removing
[   19.355113] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
[   19.376131] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1
[   19.696852] [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x40280000, bo e8ebb600
[   19.700189] Console: switching to colour frame buffer device 210x65
[   19.702106] fb0: nouveaufb frame buffer device
[   19.702108] drm: registered panic notifier
[   19.702128] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0
[   19.837176] ppdev: user-space parallel port driver
[   19.965628] type=1400 audit(1294260933.377:10): apparmor="STATUS" operation="profile_load" name="/usr/lib/cups/backend/cups-pdf" pid=758 comm="apparmor_parser"
[   19.965786] type=1400 audit(1294260933.377:11): apparmor="STATUS" operation="profile_load" name="/usr/sbin/cupsd" pid=758 comm="apparmor_parser"
[   20.734836] [drm] nouveau 0000:01:00.0: Allocating FIFO number 2
[   20.740703] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
[   20.760309] [drm] nouveau 0000:01:00.0: Allocating FIFO number 3
[   20.767016] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 3
[   22.856437] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,commit=0
[   25.804161] audit_printk_skb: 9 callbacks suppressed
[   25.804165] type=1400 audit(1294260939.214:15): apparmor="STATUS" operation="profile_load" name="/usr/bin/evince" pid=738 comm="apparmor_parser"
[   25.804820] type=1400 audit(1294260939.214:16): apparmor="STATUS" operation="profile_load" name="/usr/bin/evince-previewer" pid=738 comm="apparmor_parser"
[   25.805387] type=1400 audit(1294260939.214:17): apparmor="STATUS" operation="profile_load" name="/usr/bin/evince-thumbnailer" pid=738 comm="apparmor_parser"
[   29.200009] eth0: no IPv6 routers present
[   56.310738] [drm] nouveau 0000:01:00.0: Allocating FIFO number 4
[   56.316725] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 4
[  116.979482] lo: Disabled Privacy Extensions
[  126.367098] exe (2042): /proc/2042/oom_adj is deprecated, please use /proc/2042/oom_score_adj instead.

[announce] vfs-scale git tree update

[Nick Piggin]

Git tree is here:
  
  git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
  
Branch is: vfs-scale-working

Head is: b3e19d924b6eaf2ca7d22cba99a517c5171007b6

Changes since last posting:
* Implemented Linus' suggestions:
  - Switch the filesystem methods in one hit rather than having _rcu
    variants. This avoids a lot of cruft from core code.
  - Implement filesystem rcu-walk aware conversions in seperate patches
    after the APIs are changed, making bisectability better.
  - Change dentry_memcmp to dentry_cmp
  - Rework the way ->d_revalidate is handled to be simpler.

* Fixed configfs bug caused by switching d_op on live dentry.

* Leave d_revalidate filesystem changes out for now. The sysfs one
  in particular seems to have been causing a funny regression.

* Bit more tweaking of changelogs documentation and comments.

* Passes ltp, xfstests, dbench stressing over nfs, and some of my own
  racer tests on a couple of filesystems. Needs wider testing.

Re: [announce] vfs-scale git tree update

[Alex Elder]

On Fri, 2011-01-07 at 18:58 +1100, Nick Piggin wrote:
> Git tree is here:
>   
>   git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
>   
> Branch is: vfs-scale-working
> 
> Head is: b3e19d924b6eaf2ca7d22cba99a517c5171007b6
> 
> Changes since last posting:
> * Implemented Linus' suggestions:
>   - Switch the filesystem methods in one hit rather than having _rcu
>     variants. This avoids a lot of cruft from core code.
>   - Implement filesystem rcu-walk aware conversions in seperate patches
>     after the APIs are changed, making bisectability better.
>   - Change dentry_memcmp to dentry_cmp
>   - Rework the way ->d_revalidate is handled to be simpler.
> 
> * Fixed configfs bug caused by switching d_op on live dentry.
> 
> * Leave d_revalidate filesystem changes out for now. The sysfs one
>   in particular seems to have been causing a funny regression.
> 
> * Bit more tweaking of changelogs documentation and comments.
> 
> * Passes ltp, xfstests, dbench stressing over nfs, and some of my own
>   racer tests on a couple of filesystems. Needs wider testing.

FYI, when using this code, as merged by Linus, I hit the
BUG_ON() at the beginning of d_set_d_op() when it's called
by autofs4_dir_mkdir().  I managed to work around it by
just commenting out those BUG_ON() calls but it's something
that ought to get addressed properly.  Console grab below.

I first saw it with a kernel built from a merge of latest
XFS from oss.sgi.com with e54be894eae1... from Linus, but
I have now verified I get the same problem using Linus'
tree alone.

					-Alex

Commit: e54be894eae10eca9892e965cc9532f5d5a11767

. . .

Starting ypbind
done
Starting smartd
done
Starting automount ------------[ cut here ]------------
kernel BUG at /home/aelder/xfs/xfs/fs/dcache.c:1358!
invalid opcode: 0000 [#1] SMP 
last sysfs
file: /sys/devices/pci0000:00/0000:00:1e.0/0000:08:01.0/local_cpus
CPU 1 
Modules linked in: autofs4 binfmt_misc nfs lockd nfs_acl auth_rpcgss
sunrpc mperf ib_ipoib ib_cm ib_sa ipv6 ib_uverbs ib_umad iw_cxgb3 cxgb3
mdio mlx4_ib mlx4_core microcode fuse loop dm_mod sr_mod cdrom mptfc
ib_mthca scsi_transport_fc scsi_tgt ib_mad ib_core e1000e i5k_amb shpchp
i5000_edac rtc_cmos pci_hotplug edac_core iTCO_wdt usb_storage ioatdma
iTCO_vendor_support tpm_tis tpm container tpm_bios button dca i2c_i801
i2c_core rtc_core rtc_lib serio_raw pcspkr joydev sg usbhid hid uhci_hcd
ehci_hcd sd_mod crc_t10dif usbcore ext3 jbd mbcache piix edd xfs
exportfs fan thermal processor thermal_sys hwmon ide_generic ide_core
sata_nv megaraid_sas mptsas mptscsih mptbase scsi_transport_sas ata_piix
ahci libahci libata scsi_mod

Pid: 3848, comm: automount Not tainted 2.6.37-alex #2
X7DGT-INF/AltixXE310
RIP: 0010:[<ffffffff810e54bf>]  [<ffffffff810e54bf>] d_set_d_op+0xb/0x58
RSP: 0018:ffff88011e465e18  EFLAGS: 00010282
RAX: ffff88010c783e00 RBX: ffff88010a069800 RCX: 0000000000000013
RDX: 0000000000000000 RSI: ffffffffa02e6e80 RDI: ffff88010c78ccc0
RBP: ffff88011e465e18 R08: ffff88010a069800 R09: ffff88012268f800
R10: ffff88011185f007 R11: ffff88011e465e48 R12: ffff88010c78ccc0
R13: ffff88010a069800 R14: ffff88011c05fda0 R15: ffff8801269bb288
FS:  00007fd2db210950(0000) GS:ffff8800cfc80000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd2dc37de30 CR3: 000000010a55a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process automount (pid: 3848, threadinfo ffff88011e464000, task
ffff88010aacc1c0)
Stack:
 ffff88011e465e58 ffffffffa02e3fb7 ffff88011e465e38 0000000000000000
 ffff8801269bb288 000000000000016d ffff88010c78ccc0 00007fd2dc5c8216
 ffff88011e465e88 ffffffff810dee5d 0000000000000000 ffff88010c78ccc0
Call Trace:
 [<ffffffffa02e3fb7>] autofs4_dir_mkdir+0x124/0x19b [autofs4]
 [<ffffffff810dee5d>] vfs_mkdir+0x7e/0xd6
 [<ffffffff810e151a>] sys_mkdirat+0x91/0xe1
 [<ffffffff810e157d>] sys_mkdir+0x13/0x15
 [<ffffffff8100293b>] system_call_fastpath+0x16/0x1b
Code: 89 f7 e8 29 75 ff ff 4c 89 ff e8 d3 ce 1e 00 5a 5b 44 89 e0 41 5c
41 5d 41 5e 41 5f c9 c3 90 90 48 83 7f 60 00 55 48 89 e5 74 04 <0f> 0b
eb fe 66 f7 07 00 f0 74 04 0f 0b eb fe 48 85 f6 48 89 77 
RIP  [<ffffffff810e54bf>] d_set_d_op+0xb/0x58
 RSP <ffff88011e465e18>
---[ end trace d78cc1e6e1dedc2f ]---

Re: [announce] vfs-scale git tree update

[Linus Torvalds]

On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
>
> FYI, when using this code, as merged by Linus, I hit the
> BUG_ON() at the beginning of d_set_d_op() when it's called
> by autofs4_dir_mkdir().  I managed to work around it by
> just commenting out those BUG_ON() calls but it's something
> that ought to get addressed properly.

Yeah, removing the BUG_ON() isn't the right thing to do - it means
that autofs4 is obviously setting the dentry ops twice for the same
dentry.

Possibly the thing could be relaxed to allow setting the _same_ d_op
pointer, ie do something like

   if (dentry->d_op == op)
      return;

at the top of that function. But looking at it, I don't think that
fixes the autofs4 issue.

The fact that autofs4 does "d_add()" before it sets the d_ops (or
other dentry state, for that matter) looks a bit scary. To me that
smells like it might get a  dentry lookup hit before it's actually
fully done.

Does it make any difference if you move the various d_add() calls down
to the end of the functions to when the "dentry" has really been
instantiated?

                      Linus

Re: [announce] vfs-scale git tree update

[Alex Elder]

On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> >
> > FYI, when using this code, as merged by Linus, I hit the
> > BUG_ON() at the beginning of d_set_d_op() when it's called
> > by autofs4_dir_mkdir().  I managed to work around it by
> > just commenting out those BUG_ON() calls but it's something
> > that ought to get addressed properly.
> 
> Yeah, removing the BUG_ON() isn't the right thing to do - it means
> that autofs4 is obviously setting the dentry ops twice for the same
> dentry.
> 
> Possibly the thing could be relaxed to allow setting the _same_ d_op
> pointer, ie do something like
> 
>    if (dentry->d_op == op)
>       return;
> 
> at the top of that function. But looking at it, I don't think that
> fixes the autofs4 issue.

That's easy enough, but it seems everybody else ensures
this gets done just once per dentry, and it would be nice
to preserve that "tightness" if possible.

> The fact that autofs4 does "d_add()" before it sets the d_ops (or
> other dentry state, for that matter) looks a bit scary. To me that
> smells like it might get a  dentry lookup hit before it's actually
> fully done.

Agreed.

> Does it make any difference if you move the various d_add() calls down
> to the end of the functions to when the "dentry" has really been
> instantiated?

Looking at it quickly, I don't think that would matter for
the case at hand.  I.e., that might be safer but it doesn't
address the fact that these fields are getting initialized
multiple times.

					-Alex

Re: [announce] vfs-scale git tree update

[Linus Torvalds]

[ Added Ian to cc - the BUG_ON() in d_set_d_op() triggers on autofs4,
see lkml thread for more details if you care ]

On Tue, Jan 11, 2011 at 9:57 AM, Alex Elder <aelder@sgi.com> wrote:
>
> Looking at it quickly, I don't think that would matter for
> the case at hand.  I.e., that might be safer but it doesn't
> address the fact that these fields are getting initialized
> multiple times.

You're right - without looking closer or thinking about it any more, I
was thinking mkdir etc would create the new dentry, but it can easily
be a pre-existing negative one. So it's not like mkdir is always going
to be something new that can just be initialized.

So yeah, no race or anything like that required - just regular acceses.

That said, if we make sure that the d_op gets cleared (or the dentry
dropped) when something turns negative, and a negative lookup never
sets d_op, it should all basically work.

Can you figure out the exact sequence that causes this? Is it enough
to just mount something once?

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] vfs-scale git tree update

[Nick Piggin]

On Wed, Jan 12, 2011 at 5:13 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> [ Added Ian to cc - the BUG_ON() in d_set_d_op() triggers on autofs4,
> see lkml thread for more details if you care ]
>
> On Tue, Jan 11, 2011 at 9:57 AM, Alex Elder <aelder@sgi.com> wrote:
>>
>> Looking at it quickly, I don't think that would matter for
>> the case at hand.  I.e., that might be safer but it doesn't
>> address the fact that these fields are getting initialized
>> multiple times.
>
> You're right - without looking closer or thinking about it any more, I
> was thinking mkdir etc would create the new dentry, but it can easily
> be a pre-existing negative one. So it's not like mkdir is always going
> to be something new that can just be initialized.
>
> So yeah, no race or anything like that required - just regular acceses.
>
> That said, if we make sure that the d_op gets cleared (or the dentry
> dropped) when something turns negative, and a negative lookup never
> sets d_op, it should all basically work.
>
> Can you figure out the exact sequence that causes this? Is it enough
> to just mount something once?

Doh, sorry I probably didn't re-test autofs4 since putting that BUG_ON
in there. Now it's trivial to revert the d_set_d_op function to the same
raciness that was "allowed" before (simply by resetting the d_flags bits).
There is no new fundamental race that the patch introduced there...
But I think it is much cleaner to just fix up all filesystems, and will
potentially close obscure races.

Often the best way is to just set the same d_ops for negative and
positive dentries, and have the operations handle both cases.

Ian?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
> On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> > >
> > > FYI, when using this code, as merged by Linus, I hit the
> > > BUG_ON() at the beginning of d_set_d_op() when it's called
> > > by autofs4_dir_mkdir().  I managed to work around it by
> > > just commenting out those BUG_ON() calls but it's something
> > > that ought to get addressed properly.
> > 
> > Yeah, removing the BUG_ON() isn't the right thing to do - it means
> > that autofs4 is obviously setting the dentry ops twice for the same
> > dentry.
> > 
> > Possibly the thing could be relaxed to allow setting the _same_ d_op
> > pointer, ie do something like
> > 
> >    if (dentry->d_op == op)
> >       return;
> > 
> > at the top of that function. But looking at it, I don't think that
> > fixes the autofs4 issue.
> 
> That's easy enough, but it seems everybody else ensures
> this gets done just once per dentry, and it would be nice
> to preserve that "tightness" if possible.
> 
> > The fact that autofs4 does "d_add()" before it sets the d_ops (or
> > other dentry state, for that matter) looks a bit scary. To me that
> > smells like it might get a  dentry lookup hit before it's actually
> > fully done.
> 
> Agreed.

Isn't the parent i_mutex held during mkdir()?
Still the order can be changed, of course.

> 
> > Does it make any difference if you move the various d_add() calls down
> > to the end of the functions to when the "dentry" has really been
> > instantiated?
> 
> Looking at it quickly, I don't think that would matter for
> the case at hand.  I.e., that might be safer but it doesn't
> address the fact that these fields are getting initialized
> multiple times.

Yeah, a hangover from changes done over time.
Not setting the dentry op in ->lookup() should fix this.

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

Re: [announce] vfs-scale git tree update

[Nick Piggin]

On Wed, Jan 12, 2011 at 2:59 PM, Ian Kent <raven@themaw.net> wrote:
> On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
>> On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
>> > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
>> > >
>> > > FYI, when using this code, as merged by Linus, I hit the
>> > > BUG_ON() at the beginning of d_set_d_op() when it's called
>> > > by autofs4_dir_mkdir().  I managed to work around it by
>> > > just commenting out those BUG_ON() calls but it's something
>> > > that ought to get addressed properly.
>> >
>> > Yeah, removing the BUG_ON() isn't the right thing to do - it means
>> > that autofs4 is obviously setting the dentry ops twice for the same
>> > dentry.
>> >
>> > Possibly the thing could be relaxed to allow setting the _same_ d_op
>> > pointer, ie do something like
>> >
>> >    if (dentry->d_op == op)
>> >       return;
>> >
>> > at the top of that function. But looking at it, I don't think that
>> > fixes the autofs4 issue.
>>
>> That's easy enough, but it seems everybody else ensures
>> this gets done just once per dentry, and it would be nice
>> to preserve that "tightness" if possible.
>>
>> > The fact that autofs4 does "d_add()" before it sets the d_ops (or
>> > other dentry state, for that matter) looks a bit scary. To me that
>> > smells like it might get a  dentry lookup hit before it's actually
>> > fully done.
>>
>> Agreed.
>
> Isn't the parent i_mutex held during mkdir()?

Yes but there are concurrency cases allowed without i_mutex.

Lookup, for example, which ends up touching d_revalidate and
when dropping the dentry, possibly d_delete.

There seems no benefit to allowing switch of d_ops on a live
dentry, and many downsides. So the rule should just be that it
is not allowed.


> Still the order can be changed, of course.
>
>>
>> > Does it make any difference if you move the various d_add() calls down
>> > to the end of the functions to when the "dentry" has really been
>> > instantiated?
>>
>> Looking at it quickly, I don't think that would matter for
>> the case at hand.  I.e., that might be safer but it doesn't
>> address the fact that these fields are getting initialized
>> multiple times.
>
> Yeah, a hangover from changes done over time.
> Not setting the dentry op in ->lookup() should fix this.

How about negative dentries? They should be set up with d_ops
upon allocation, preferably if your operations can handle negative
dentries.

Thanks,
Nick

Re: [announce] vfs-scale git tree update

[Linus Torvalds]

On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent <raven@themaw.net> wrote:
>
> Isn't the parent i_mutex held during mkdir()?

Yes, but a lookup that hits in the dentry cache won't actually take
the parent mutex.

So as far as I can tell, doing the "d_add()" before setting d_op can
result in another CPU coming in and seeing the newly added dentry
before d_op has actually been initialized. Exactly because it will do
the dentry lookup without holding any mutex.

Of course, it's a very small window, so it probably doesn't matter in practice.

>> Looking at it quickly, I don't think that would matter for
>> the case at hand.  I.e., that might be safer but it doesn't
>> address the fact that these fields are getting initialized
>> multiple times.
>
> Yeah, a hangover from changes done over time.
> Not setting the dentry op in ->lookup() should fix this.

Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()?

(That code is a bit scary, though - it explicitly makes it a negative
dentry with a d_instantiate(dentry, NULL), and then hides the inode
information away separately. Scary scary)

              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Tue, 2011-01-11 at 20:06 -0800, Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent <raven@themaw.net> wrote:
> >
> > Isn't the parent i_mutex held during mkdir()?
> 
> Yes, but a lookup that hits in the dentry cache won't actually take
> the parent mutex.
> 
> So as far as I can tell, doing the "d_add()" before setting d_op can
> result in another CPU coming in and seeing the newly added dentry
> before d_op has actually been initialized. Exactly because it will do
> the dentry lookup without holding any mutex.
> 
> Of course, it's a very small window, so it probably doesn't matter in practice.
> 
> >> Looking at it quickly, I don't think that would matter for
> >> the case at hand.  I.e., that might be safer but it doesn't
> >> address the fact that these fields are getting initialized
> >> multiple times.
> >
> > Yeah, a hangover from changes done over time.
> > Not setting the dentry op in ->lookup() should fix this.
> 
> Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()?
> 
> (That code is a bit scary, though - it explicitly makes it a negative
> dentry with a d_instantiate(dentry, NULL), and then hides the inode
> information away separately. Scary scary)

Yeah, but the expire to mount races with autofs are difficult to handle
and this approach has worked well under heavy stress testing. It's true
that this would almost certainly be bad for a file system that supported
a full range of functionality but that's not so for autofs.

> 
>               Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Wed, 2011-01-12 at 12:41 +0800, Ian Kent wrote:
> On Tue, 2011-01-11 at 20:06 -0800, Linus Torvalds wrote:
> > On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent <raven@themaw.net> wrote:
> > >
> > > Isn't the parent i_mutex held during mkdir()?
> > 
> > Yes, but a lookup that hits in the dentry cache won't actually take
> > the parent mutex.
> > 
> > So as far as I can tell, doing the "d_add()" before setting d_op can
> > result in another CPU coming in and seeing the newly added dentry
> > before d_op has actually been initialized. Exactly because it will do
> > the dentry lookup without holding any mutex.
> > 
> > Of course, it's a very small window, so it probably doesn't matter in practice.
> > 
> > >> Looking at it quickly, I don't think that would matter for
> > >> the case at hand.  I.e., that might be safer but it doesn't
> > >> address the fact that these fields are getting initialized
> > >> multiple times.
> > >
> > > Yeah, a hangover from changes done over time.
> > > Not setting the dentry op in ->lookup() should fix this.
> > 
> > Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()?
> > 
> > (That code is a bit scary, though - it explicitly makes it a negative
> > dentry with a d_instantiate(dentry, NULL), and then hides the inode
> > information away separately. Scary scary)
> 
> Yeah, but the expire to mount races with autofs are difficult to handle
> and this approach has worked well under heavy stress testing. It's true
> that this would almost certainly be bad for a file system that supported
> a full range of functionality but that's not so for autofs.

I think I have to partly take this back.
With Nick's recent vfs-scale patches this may not be OK any more since
the dcache_lock has gone away and, at first glance, it looks like the
added autofs4_lock spin lock doesn't provide the needed protection.

Ian

Re: [announce] vfs-scale git tree update

[Nick Piggin]

On Wed, Jan 12, 2011 at 4:17 PM, Ian Kent <raven@themaw.net> wrote:
> On Wed, 2011-01-12 at 12:41 +0800, Ian Kent wrote:
>> On Tue, 2011-01-11 at 20:06 -0800, Linus Torvalds wrote:
>> > On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent <raven@themaw.net> wrote:

>> > > Yeah, a hangover from changes done over time.
>> > > Not setting the dentry op in ->lookup() should fix this.
>> >
>> > Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()?
>> >
>> > (That code is a bit scary, though - it explicitly makes it a negative
>> > dentry with a d_instantiate(dentry, NULL), and then hides the inode
>> > information away separately. Scary scary)
>>
>> Yeah, but the expire to mount races with autofs are difficult to handle
>> and this approach has worked well under heavy stress testing. It's true
>> that this would almost certainly be bad for a file system that supported
>> a full range of functionality but that's not so for autofs.
>
> I think I have to partly take this back.
> With Nick's recent vfs-scale patches this may not be OK any more since
> the dcache_lock has gone away and, at first glance, it looks like the
> added autofs4_lock spin lock doesn't provide the needed protection.

Hm, what are the concurrencies that you need protection from?

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Thu, 2011-01-13 at 12:01 +1100, Nick Piggin wrote:
> On Wed, Jan 12, 2011 at 4:17 PM, Ian Kent <raven@themaw.net> wrote:
> > On Wed, 2011-01-12 at 12:41 +0800, Ian Kent wrote:
> >> On Tue, 2011-01-11 at 20:06 -0800, Linus Torvalds wrote:
> >> > On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent <raven@themaw.net> wrote:
> 
> >> > > Yeah, a hangover from changes done over time.
> >> > > Not setting the dentry op in ->lookup() should fix this.
> >> >
> >> > Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()?
> >> >
> >> > (That code is a bit scary, though - it explicitly makes it a negative
> >> > dentry with a d_instantiate(dentry, NULL), and then hides the inode
> >> > information away separately. Scary scary)
> >>
> >> Yeah, but the expire to mount races with autofs are difficult to handle
> >> and this approach has worked well under heavy stress testing. It's true
> >> that this would almost certainly be bad for a file system that supported
> >> a full range of functionality but that's not so for autofs.
> >
> > I think I have to partly take this back.
> > With Nick's recent vfs-scale patches this may not be OK any more since
> > the dcache_lock has gone away and, at first glance, it looks like the
> > added autofs4_lock spin lock doesn't provide the needed protection.
> 
> Hm, what are the concurrencies that you need protection from?

Ha, I think I'm wrong about this, after looking more closely at this I'm
struggling to see why autofs4_lock is needed at all.

Re: [announce] vfs-scale git tree update

[Nick Piggin]

On Thu, Jan 13, 2011 at 12:48 PM, Ian Kent <raven@themaw.net> wrote:
> On Thu, 2011-01-13 at 12:01 +1100, Nick Piggin wrote:
>> Hm, what are the concurrencies that you need protection from?
>
> Ha, I think I'm wrong about this, after looking more closely at this I'm
> struggling to see why autofs4_lock is needed at all.

Well you did send me a series of patches to remove it, but
unfortunately that was just as you made some larger changes
to autofs4 upstream and I wasn't able to keep them up to date.

It would be much appreciated if you had time to take another
look at all the locking and streamline it.

Thanks,
Nick

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Thu, 2011-01-13 at 13:14 +1100, Nick Piggin wrote:
> On Thu, Jan 13, 2011 at 12:48 PM, Ian Kent <raven@themaw.net> wrote:
> > On Thu, 2011-01-13 at 12:01 +1100, Nick Piggin wrote:
> >> Hm, what are the concurrencies that you need protection from?
> >
> > Ha, I think I'm wrong about this, after looking more closely at this I'm
> > struggling to see why autofs4_lock is needed at all.
> 
> Well you did send me a series of patches to remove it, but
> unfortunately that was just as you made some larger changes
> to autofs4 upstream and I wasn't able to keep them up to date.
> 
> It would be much appreciated if you had time to take another
> look at all the locking and streamline it.

I have started looking at it but just the autofs4_lock.

As you know, we have some significant autofs changes in progress, so I
don't want to spend a huge amount of time testing (and the testing does
take a long time) against source that will be very different. So far I
can't see that the autofs4_lock will introduce any problem so I want to
leave it for now and (probably) eliminate it in the new code since that
will need changes as well and will need to be re-tested.

I'd appreciate it if you could find time to reply to David's questions
about the changes to our d_automount patch series. Although, based on
our previous discussion, I think he has it about right, but a word or
two from you would be really helpful.

Ian

Re: [announce] vfs-scale git tree update

[Nick Piggin]

On Thu, Jan 13, 2011 at 2:20 PM, Ian Kent <raven@themaw.net> wrote:
> On Thu, 2011-01-13 at 13:14 +1100, Nick Piggin wrote:
>> On Thu, Jan 13, 2011 at 12:48 PM, Ian Kent <raven@themaw.net> wrote:
>> > On Thu, 2011-01-13 at 12:01 +1100, Nick Piggin wrote:
>> >> Hm, what are the concurrencies that you need protection from?
>> >
>> > Ha, I think I'm wrong about this, after looking more closely at this I'm
>> > struggling to see why autofs4_lock is needed at all.
>>
>> Well you did send me a series of patches to remove it, but
>> unfortunately that was just as you made some larger changes
>> to autofs4 upstream and I wasn't able to keep them up to date.
>>
>> It would be much appreciated if you had time to take another
>> look at all the locking and streamline it.
>
> I have started looking at it but just the autofs4_lock.
>
> As you know, we have some significant autofs changes in progress, so I
> don't want to spend a huge amount of time testing (and the testing does
> take a long time) against source that will be very different. So far I
> can't see that the autofs4_lock will introduce any problem so I want to
> leave it for now and (probably) eliminate it in the new code since that
> will need changes as well and will need to be re-tested.

Fair enough.


> I'd appreciate it if you could find time to reply to David's questions
> about the changes to our d_automount patch series. Although, based on
> our previous discussion, I think he has it about right, but a word or
> two from you would be really helpful.

Yes I am meaning to take a look, I'm a bit busy for the next week,
however.

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Wed, 2011-01-12 at 11:59 +0800, Ian Kent wrote:
> On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
> > On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> > > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> > > >
> > > > FYI, when using this code, as merged by Linus, I hit the
> > > > BUG_ON() at the beginning of d_set_d_op() when it's called
> > > > by autofs4_dir_mkdir().  I managed to work around it by
> > > > just commenting out those BUG_ON() calls but it's something
> > > > that ought to get addressed properly.
> > > 
> > > Yeah, removing the BUG_ON() isn't the right thing to do - it means
> > > that autofs4 is obviously setting the dentry ops twice for the same
> > > dentry.
> > > 
> > > Possibly the thing could be relaxed to allow setting the _same_ d_op
> > > pointer, ie do something like
> > > 
> > >    if (dentry->d_op == op)
> > >       return;
> > > 
> > > at the top of that function. But looking at it, I don't think that
> > > fixes the autofs4 issue.
> > 
> > That's easy enough, but it seems everybody else ensures
> > this gets done just once per dentry, and it would be nice
> > to preserve that "tightness" if possible.
> > 
> > > The fact that autofs4 does "d_add()" before it sets the d_ops (or
> > > other dentry state, for that matter) looks a bit scary. To me that
> > > smells like it might get a  dentry lookup hit before it's actually
> > > fully done.
> > 
> > Agreed.
> 
> Isn't the parent i_mutex held during mkdir()?
> Still the order can be changed, of course.
> 
> > 
> > > Does it make any difference if you move the various d_add() calls down
> > > to the end of the functions to when the "dentry" has really been
> > > instantiated?
> > 
> > Looking at it quickly, I don't think that would matter for
> > the case at hand.  I.e., that might be safer but it doesn't
> > address the fact that these fields are getting initialized
> > multiple times.
> 
> Yeah, a hangover from changes done over time.
> Not setting the dentry op in ->lookup() should fix this.

Could you try this patch please.

autofs4 - dont set dentry op in ->lookup()

From: Ian Kent <raven@themaw.net>

With the introduction of the vfs-scale patch series setting dentry
operations more than once (or changing them) triggers a BUG_ON().

Also, move the d_add() in ->symlink() and ->mkdir() to the end of
the function.
---

 fs/autofs4/root.c |   19 ++++---------------
 1 files changed, 4 insertions(+), 15 deletions(-)


diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 651e4ef..a9a41eb 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -568,19 +568,6 @@ static struct dentry *autofs4_lookup(struct inode *dir, struct dentry *dentry, s
 		ino = autofs4_dentry_ino(dentry);
 	} else {
 		/*
-		 * Mark the dentry incomplete but don't hash it. We do this
-		 * to serialize our inode creation operations (symlink and
-		 * mkdir) which prevents deadlock during the callback to
-		 * the daemon. Subsequent user space lookups for the same
-		 * dentry are placed on the wait queue while the daemon
-		 * itself is allowed passage unresticted so the create
-		 * operation itself can then hash the dentry. Finally,
-		 * we check for the hashed dentry and return the newly
-		 * hashed dentry.
-		 */
-		d_set_d_op(dentry, &autofs4_root_dentry_operations);
-
-		/*
 		 * And we need to ensure that the same dentry is used for
 		 * all following lookup calls until it is hashed so that
 		 * the dentry flags are persistent throughout the request.
@@ -714,7 +701,6 @@ static int autofs4_dir_symlink(struct inode *dir,
 			kfree(ino);
 		return -ENOMEM;
 	}
-	d_add(dentry, inode);
 
 	if (dir == dir->i_sb->s_root->d_inode)
 		d_set_d_op(dentry, &autofs4_root_dentry_operations);
@@ -732,6 +718,8 @@ static int autofs4_dir_symlink(struct inode *dir,
 	ino->u.symlink = cp;
 	dir->i_mtime = CURRENT_TIME;
 
+	d_add(dentry, inode);
+
 	return 0;
 }
 
@@ -849,7 +837,6 @@ static int autofs4_dir_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 			kfree(ino);
 		return -ENOMEM;
 	}
-	d_add(dentry, inode);
 
 	if (dir == dir->i_sb->s_root->d_inode)
 		d_set_d_op(dentry, &autofs4_root_dentry_operations);
@@ -866,6 +853,8 @@ static int autofs4_dir_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 	inc_nlink(dir);
 	dir->i_mtime = CURRENT_TIME;
 
+	d_add(dentry, inode);
+
 	return 0;
 }
 

Re: [announce] vfs-scale git tree update

[Alex Elder]

On Wed, 2011-01-12 at 12:15 +0800, Ian Kent wrote:
> On Wed, 2011-01-12 at 11:59 +0800, Ian Kent wrote:
> > On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
> > > On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> > > > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> > > > >
> > > > > FYI, when using this code, as merged by Linus, I hit the
> > > > > BUG_ON() at the beginning of d_set_d_op() when it's called
> > > > > by autofs4_dir_mkdir().  I managed to work around it by
> > > > > just commenting out those BUG_ON() calls but it's something
> > > > > that ought to get addressed properly.
> > > > 
> > > > Yeah, removing the BUG_ON() isn't the right thing to do - it means
> > > > that autofs4 is obviously setting the dentry ops twice for the same
> > > > dentry.
> > > > 
> > > > Possibly the thing could be relaxed to allow setting the _same_ d_op
> > > > pointer, ie do something like
> > > > 
> > > >    if (dentry->d_op == op)
> > > >       return;
> > > > 
> > > > at the top of that function. But looking at it, I don't think that
> > > > fixes the autofs4 issue.
> > > 
> > > That's easy enough, but it seems everybody else ensures
> > > this gets done just once per dentry, and it would be nice
> > > to preserve that "tightness" if possible.
> > > 
> > > > The fact that autofs4 does "d_add()" before it sets the d_ops (or
> > > > other dentry state, for that matter) looks a bit scary. To me that
> > > > smells like it might get a  dentry lookup hit before it's actually
> > > > fully done.
> > > 
> > > Agreed.
> > 
> > Isn't the parent i_mutex held during mkdir()?
> > Still the order can be changed, of course.
> > 
> > > 
> > > > Does it make any difference if you move the various d_add() calls down
> > > > to the end of the functions to when the "dentry" has really been
> > > > instantiated?
> > > 
> > > Looking at it quickly, I don't think that would matter for
> > > the case at hand.  I.e., that might be safer but it doesn't
> > > address the fact that these fields are getting initialized
> > > multiple times.
> > 
> > Yeah, a hangover from changes done over time.
> > Not setting the dentry op in ->lookup() should fix this.
> 
> Could you try this patch please.

OK, sorry for the delay.  I tried the patch.  I applied
it against 4162cf64973df51fc885825bc9ca4d055891c49f,
which is the linus/master branch I had on hand.  This
time I got a different failure due to a null pointer
dereference.  Console capture below.  I can log
in still but the boot sequence never got to the
login prompt on the console as it normally does.

					-Alex

> autofs4 - dont set dentry op in ->lookup()

. . .
Starting smartd
done
Starting network time protocol daemon (NTPD)
done
Starting automount BUG: unable to handle kernel NULL pointer dereference
at 0000000000000010
IP: [<ffffffffa0296744>] autofs4_lookup+0x3dd/0x4a7 [autofs4]
PGD 0 
Oops: 0000 [#1] SMP 
last sysfs
file: /sys/devices/pci0000:00/0000:00:1e.0/0000:08:01.0/local_cpus
CPU 2 
Modules linked in: autofs4 binfmt_misc nfs lockd nfs_acl auth_rpcgss
sunrpc ib_ipoib ib_cm ib_sa ipv6 mperf ib_uverbs ib_umad iw_cxgb3 cxgb3
mdio mlx4_ib mlx4_core microcode fuse loop dm_mod sr_mod cdrom ib_mthca
ib_mad e1000e mptfc scsi_transport_fc scsi_tgt ib_core shpchp
usb_storage i5k_amb pci_hotplug rtc_cmos rtc_core iTCO_wdt rtc_lib
tpm_tis i2c_i801 i2c_core ioatdma dca tpm i5000_edac iTCO_vendor_support
edac_core pcspkr container button joydev tpm_bios serio_raw sg usbhid
hid uhci_hcd ehci_hcd sd_mod crc_t10dif usbcore ext3 jbd mbcache piix
edd xfs exportfs fan thermal processor thermal_sys hwmon ide_generic
ide_core sata_nv megaraid_sas mptsas mptscsih mptbase scsi_transport_sas
ata_piix ahci libahci libata scsi_mod

Pid: 3880, comm: automount Not tainted 2.6.37-alex #1
X7DGT-INF/AltixXE310
RIP: 0010:[<ffffffffa0296744>]  [<ffffffffa0296744>] autofs4_lookup
+0x3dd/0x4a7 [autofs4]
RSP: 0018:ffff88011f7a3b88  EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff880117faeb40 RCX: 0000000000000011
RDX: 0000000000000000 RSI: ffff88011ecfcb38 RDI: ffff88011ecfcb38
RBP: ffff88011f7a3c38 R08: 0000000000000000 R09: ffff88011ed41578
R10: ffff880120f4c007 R11: 000000000000343e R12: ffff880117fae9f8
R13: ffff88011ecfcb00 R14: 0000000000000001 R15: ffff88011ecfcb00
FS:  00007ffb9915a950(0000) GS:ffff8800cfd00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000010 CR3: 000000011e7d1000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process automount (pid: 3880, threadinfo ffff88011f7a2000, task
ffff880124628480)
Stack:
 ffff88011f7a3c08 0000000000000011 ffff88012ffd9e00 ffff88011f7a3db8
 ffff880120247050 ffff8800cfd0e0e0 ffff880117faeb40 0000000000000000
 00000001249405f8 ffff880117faebc0 ffff88011ecfcb38 00000011dc2bc535
Call Trace:
 [<ffffffff810e86fb>] ? d_alloc+0x165/0x1bd
 [<ffffffff810de19e>] d_alloc_and_lookup+0x49/0x68
 [<ffffffff810de34c>] do_lookup+0x18f/0x23a
 [<ffffffff810e07a9>] link_path_walk+0x5ad/0xa90
 [<ffffffff810e0edd>] do_path_lookup+0x4b/0x107
 [<ffffffff810e1973>] user_path_at+0x52/0x8c
 [<ffffffff810d91fe>] ? cp_new_stat+0xe2/0xee
 [<ffffffff810e7525>] ? dput+0x25/0x23e
 [<ffffffff810d93bc>] vfs_fstatat+0x35/0x62
 [<ffffffff810d94cb>] vfs_stat+0x16/0x18
 [<ffffffff810d94e7>] sys_newstat+0x1a/0x3b
 [<ffffffff8100293b>] system_call_fastpath+0x16/0x1b
Code: 47 60 48 85 c0 74 14 48 8b 00 48 85 c0 74 0c 48 8b b5 68 ff ff ff
4c 89 ff ff d0 48 8b bd 78 ff ff ff e8 79 c1 03 e1 48 8b 55 88 <f6> 42
10 04 74 76 65 48 8b 14 25 80 b5 00 00 48 8b 42 08 48 8b 
RIP  [<ffffffffa0296744>] autofs4_lookup+0x3dd/0x4a7 [autofs4]
 RSP <ffff88011f7a3b88>
CR2: 0000000000000010
---[ end trace 6655d1f57e42cf9e ]---
Starting mail service (Postfix)
done
Starting CRON daemon
done
eth0: no IPv6 routers present

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Wed, 2011-01-12 at 14:11 -0600, Alex Elder wrote:
> On Wed, 2011-01-12 at 12:15 +0800, Ian Kent wrote:
> > On Wed, 2011-01-12 at 11:59 +0800, Ian Kent wrote:
> > > On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
> > > > On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> > > > > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> > > > > >
> > > > > > FYI, when using this code, as merged by Linus, I hit the
> > > > > > BUG_ON() at the beginning of d_set_d_op() when it's called
> > > > > > by autofs4_dir_mkdir().  I managed to work around it by
> > > > > > just commenting out those BUG_ON() calls but it's something
> > > > > > that ought to get addressed properly.
> > > > > 
> > > > > Yeah, removing the BUG_ON() isn't the right thing to do - it means
> > > > > that autofs4 is obviously setting the dentry ops twice for the same
> > > > > dentry.
> > > > > 
> > > > > Possibly the thing could be relaxed to allow setting the _same_ d_op
> > > > > pointer, ie do something like
> > > > > 
> > > > >    if (dentry->d_op == op)
> > > > >       return;
> > > > > 
> > > > > at the top of that function. But looking at it, I don't think that
> > > > > fixes the autofs4 issue.
> > > > 
> > > > That's easy enough, but it seems everybody else ensures
> > > > this gets done just once per dentry, and it would be nice
> > > > to preserve that "tightness" if possible.
> > > > 
> > > > > The fact that autofs4 does "d_add()" before it sets the d_ops (or
> > > > > other dentry state, for that matter) looks a bit scary. To me that
> > > > > smells like it might get a  dentry lookup hit before it's actually
> > > > > fully done.
> > > > 
> > > > Agreed.
> > > 
> > > Isn't the parent i_mutex held during mkdir()?
> > > Still the order can be changed, of course.
> > > 
> > > > 
> > > > > Does it make any difference if you move the various d_add() calls down
> > > > > to the end of the functions to when the "dentry" has really been
> > > > > instantiated?
> > > > 
> > > > Looking at it quickly, I don't think that would matter for
> > > > the case at hand.  I.e., that might be safer but it doesn't
> > > > address the fact that these fields are getting initialized
> > > > multiple times.
> > > 
> > > Yeah, a hangover from changes done over time.
> > > Not setting the dentry op in ->lookup() should fix this.
> > 
> > Could you try this patch please.
> 
> OK, sorry for the delay.  I tried the patch.  I applied
> it against 4162cf64973df51fc885825bc9ca4d055891c49f,
> which is the linus/master branch I had on hand.  This
> time I got a different failure due to a null pointer
> dereference.  Console capture below.  I can log
> in still but the boot sequence never got to the
> login prompt on the console as it normally does.


Sorry, that is rather an obvious mistake on my part.
There's a call to d_op->d_revalidate() just below where the dentry
operations are set. I'm tempted to just call the revalidate function
directly since it is always called anyway. But let me check we've done
in the our current of tree autofs patch series first.

> 
> 					-Alex
> 
> > autofs4 - dont set dentry op in ->lookup()
> 
> . . .
> Starting smartd
> done
> Starting network time protocol daemon (NTPD)
> done
> Starting automount BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000010
> IP: [<ffffffffa0296744>] autofs4_lookup+0x3dd/0x4a7 [autofs4]
> PGD 0 
> Oops: 0000 [#1] SMP 
> last sysfs
> file: /sys/devices/pci0000:00/0000:00:1e.0/0000:08:01.0/local_cpus
> CPU 2 
> Modules linked in: autofs4 binfmt_misc nfs lockd nfs_acl auth_rpcgss
> sunrpc ib_ipoib ib_cm ib_sa ipv6 mperf ib_uverbs ib_umad iw_cxgb3 cxgb3
> mdio mlx4_ib mlx4_core microcode fuse loop dm_mod sr_mod cdrom ib_mthca
> ib_mad e1000e mptfc scsi_transport_fc scsi_tgt ib_core shpchp
> usb_storage i5k_amb pci_hotplug rtc_cmos rtc_core iTCO_wdt rtc_lib
> tpm_tis i2c_i801 i2c_core ioatdma dca tpm i5000_edac iTCO_vendor_support
> edac_core pcspkr container button joydev tpm_bios serio_raw sg usbhid
> hid uhci_hcd ehci_hcd sd_mod crc_t10dif usbcore ext3 jbd mbcache piix
> edd xfs exportfs fan thermal processor thermal_sys hwmon ide_generic
> ide_core sata_nv megaraid_sas mptsas mptscsih mptbase scsi_transport_sas
> ata_piix ahci libahci libata scsi_mod
> 
> Pid: 3880, comm: automount Not tainted 2.6.37-alex #1
> X7DGT-INF/AltixXE310
> RIP: 0010:[<ffffffffa0296744>]  [<ffffffffa0296744>] autofs4_lookup
> +0x3dd/0x4a7 [autofs4]
> RSP: 0018:ffff88011f7a3b88  EFLAGS: 00010202
> RAX: 0000000000000002 RBX: ffff880117faeb40 RCX: 0000000000000011
> RDX: 0000000000000000 RSI: ffff88011ecfcb38 RDI: ffff88011ecfcb38
> RBP: ffff88011f7a3c38 R08: 0000000000000000 R09: ffff88011ed41578
> R10: ffff880120f4c007 R11: 000000000000343e R12: ffff880117fae9f8
> R13: ffff88011ecfcb00 R14: 0000000000000001 R15: ffff88011ecfcb00
> FS:  00007ffb9915a950(0000) GS:ffff8800cfd00000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000010 CR3: 000000011e7d1000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process automount (pid: 3880, threadinfo ffff88011f7a2000, task
> ffff880124628480)
> Stack:
>  ffff88011f7a3c08 0000000000000011 ffff88012ffd9e00 ffff88011f7a3db8
>  ffff880120247050 ffff8800cfd0e0e0 ffff880117faeb40 0000000000000000
>  00000001249405f8 ffff880117faebc0 ffff88011ecfcb38 00000011dc2bc535
> Call Trace:
>  [<ffffffff810e86fb>] ? d_alloc+0x165/0x1bd
>  [<ffffffff810de19e>] d_alloc_and_lookup+0x49/0x68
>  [<ffffffff810de34c>] do_lookup+0x18f/0x23a
>  [<ffffffff810e07a9>] link_path_walk+0x5ad/0xa90
>  [<ffffffff810e0edd>] do_path_lookup+0x4b/0x107
>  [<ffffffff810e1973>] user_path_at+0x52/0x8c
>  [<ffffffff810d91fe>] ? cp_new_stat+0xe2/0xee
>  [<ffffffff810e7525>] ? dput+0x25/0x23e
>  [<ffffffff810d93bc>] vfs_fstatat+0x35/0x62
>  [<ffffffff810d94cb>] vfs_stat+0x16/0x18
>  [<ffffffff810d94e7>] sys_newstat+0x1a/0x3b
>  [<ffffffff8100293b>] system_call_fastpath+0x16/0x1b
> Code: 47 60 48 85 c0 74 14 48 8b 00 48 85 c0 74 0c 48 8b b5 68 ff ff ff
> 4c 89 ff ff d0 48 8b bd 78 ff ff ff e8 79 c1 03 e1 48 8b 55 88 <f6> 42
> 10 04 74 76 65 48 8b 14 25 80 b5 00 00 48 8b 42 08 48 8b 
> RIP  [<ffffffffa0296744>] autofs4_lookup+0x3dd/0x4a7 [autofs4]
>  RSP <ffff88011f7a3b88>
> CR2: 0000000000000010
> ---[ end trace 6655d1f57e42cf9e ]---
> Starting mail service (Postfix)
> done
> Starting CRON daemon
> done
> eth0: no IPv6 routers present
> 
> 

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Thu, 2011-01-13 at 10:23 +0800, Ian Kent wrote:
> On Wed, 2011-01-12 at 14:11 -0600, Alex Elder wrote:
> > On Wed, 2011-01-12 at 12:15 +0800, Ian Kent wrote:
> > > On Wed, 2011-01-12 at 11:59 +0800, Ian Kent wrote:
> > > > On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
> > > > > On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> > > > > > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> > > > > > >
> > > > > > > FYI, when using this code, as merged by Linus, I hit the
> > > > > > > BUG_ON() at the beginning of d_set_d_op() when it's called
> > > > > > > by autofs4_dir_mkdir().  I managed to work around it by
> > > > > > > just commenting out those BUG_ON() calls but it's something
> > > > > > > that ought to get addressed properly.
> > > > > > 
> > > > > > Yeah, removing the BUG_ON() isn't the right thing to do - it means
> > > > > > that autofs4 is obviously setting the dentry ops twice for the same
> > > > > > dentry.
> > > > > > 
> > > > > > Possibly the thing could be relaxed to allow setting the _same_ d_op
> > > > > > pointer, ie do something like
> > > > > > 
> > > > > >    if (dentry->d_op == op)
> > > > > >       return;
> > > > > > 
> > > > > > at the top of that function. But looking at it, I don't think that
> > > > > > fixes the autofs4 issue.
> > > > > 
> > > > > That's easy enough, but it seems everybody else ensures
> > > > > this gets done just once per dentry, and it would be nice
> > > > > to preserve that "tightness" if possible.
> > > > > 
> > > > > > The fact that autofs4 does "d_add()" before it sets the d_ops (or
> > > > > > other dentry state, for that matter) looks a bit scary. To me that
> > > > > > smells like it might get a  dentry lookup hit before it's actually
> > > > > > fully done.
> > > > > 
> > > > > Agreed.
> > > > 
> > > > Isn't the parent i_mutex held during mkdir()?
> > > > Still the order can be changed, of course.
> > > > 
> > > > > 
> > > > > > Does it make any difference if you move the various d_add() calls down
> > > > > > to the end of the functions to when the "dentry" has really been
> > > > > > instantiated?
> > > > > 
> > > > > Looking at it quickly, I don't think that would matter for
> > > > > the case at hand.  I.e., that might be safer but it doesn't
> > > > > address the fact that these fields are getting initialized
> > > > > multiple times.
> > > > 
> > > > Yeah, a hangover from changes done over time.
> > > > Not setting the dentry op in ->lookup() should fix this.
> > > 
> > > Could you try this patch please.
> > 
> > OK, sorry for the delay.  I tried the patch.  I applied
> > it against 4162cf64973df51fc885825bc9ca4d055891c49f,
> > which is the linus/master branch I had on hand.  This
> > time I got a different failure due to a null pointer
> > dereference.  Console capture below.  I can log
> > in still but the boot sequence never got to the
> > login prompt on the console as it normally does.
> 
> 
> Sorry, that is rather an obvious mistake on my part.
> There's a call to d_op->d_revalidate() just below where the dentry
> operations are set. I'm tempted to just call the revalidate function
> directly since it is always called anyway. But let me check we've done
> in the our current of tree autofs patch series first.

Ha, there is no revalidate in the current not yet merged autofs.
So I think we just need to work around it.

Try this and see if it resolves the issue.

autofs4 - set dentry op in ->lookup() only

From: Ian Kent <raven@themaw.net>

With the introduction of the vfs-scale patch series setting dentry
operations more than once (or changing them) triggers a BUG_ON().
Since the two dentry operations used are the same, just set the
operations in ->lookup() and remove the set in ->symlink() and
->mkdir().

Also, move the d_add() in ->symlink() and ->mkdir() to the end of
the function.
---

 fs/autofs4/root.c |   40 +++++++---------------------------------
 1 files changed, 7 insertions(+), 33 deletions(-)


diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 651e4ef..0897706 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -419,12 +419,6 @@ void autofs4_dentry_release(struct dentry *de)
 	}
 }
 
-/* For dentries of directories in the root dir */
-static const struct dentry_operations autofs4_root_dentry_operations = {
-	.d_revalidate	= autofs4_revalidate,
-	.d_release	= autofs4_dentry_release,
-};
-
 /* For other dentries */
 static const struct dentry_operations autofs4_dentry_operations = {
 	.d_revalidate	= autofs4_revalidate,
@@ -568,19 +562,6 @@ static struct dentry *autofs4_lookup(struct inode *dir, struct dentry *dentry, s
 		ino = autofs4_dentry_ino(dentry);
 	} else {
 		/*
-		 * Mark the dentry incomplete but don't hash it. We do this
-		 * to serialize our inode creation operations (symlink and
-		 * mkdir) which prevents deadlock during the callback to
-		 * the daemon. Subsequent user space lookups for the same
-		 * dentry are placed on the wait queue while the daemon
-		 * itself is allowed passage unresticted so the create
-		 * operation itself can then hash the dentry. Finally,
-		 * we check for the hashed dentry and return the newly
-		 * hashed dentry.
-		 */
-		d_set_d_op(dentry, &autofs4_root_dentry_operations);
-
-		/*
 		 * And we need to ensure that the same dentry is used for
 		 * all following lookup calls until it is hashed so that
 		 * the dentry flags are persistent throughout the request.
@@ -589,6 +570,8 @@ static struct dentry *autofs4_lookup(struct inode *dir, struct dentry *dentry, s
 		if (!ino)
 			return ERR_PTR(-ENOMEM);
 
+		d_set_d_op(dentry, &autofs4_dentry_operations);
+
 		dentry->d_fsdata = ino;
 		ino->dentry = dentry;
 
@@ -714,12 +697,6 @@ static int autofs4_dir_symlink(struct inode *dir,
 			kfree(ino);
 		return -ENOMEM;
 	}
-	d_add(dentry, inode);
-
-	if (dir == dir->i_sb->s_root->d_inode)
-		d_set_d_op(dentry, &autofs4_root_dentry_operations);
-	else
-		d_set_d_op(dentry, &autofs4_dentry_operations);
 
 	dentry->d_fsdata = ino;
 	ino->dentry = dget(dentry);
@@ -732,6 +709,8 @@ static int autofs4_dir_symlink(struct inode *dir,
 	ino->u.symlink = cp;
 	dir->i_mtime = CURRENT_TIME;
 
+	d_add(dentry, inode);
+
 	return 0;
 }
 
@@ -849,12 +828,6 @@ static int autofs4_dir_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 			kfree(ino);
 		return -ENOMEM;
 	}
-	d_add(dentry, inode);
-
-	if (dir == dir->i_sb->s_root->d_inode)
-		d_set_d_op(dentry, &autofs4_root_dentry_operations);
-	else
-		d_set_d_op(dentry, &autofs4_dentry_operations);
 
 	dentry->d_fsdata = ino;
 	ino->dentry = dget(dentry);
@@ -866,6 +839,8 @@ static int autofs4_dir_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 	inc_nlink(dir);
 	dir->i_mtime = CURRENT_TIME;
 
+	d_add(dentry, inode);
+
 	return 0;
 }
 
@@ -944,8 +919,7 @@ static inline int autofs4_ask_umount(struct vfsmount *mnt, int __user *p)
 int is_autofs4_dentry(struct dentry *dentry)
 {
 	return dentry && dentry->d_inode &&
-		(dentry->d_op == &autofs4_root_dentry_operations ||
-		 dentry->d_op == &autofs4_dentry_operations) &&
+		(dentry->d_op == &autofs4_dentry_operations) &&
 		dentry->d_fsdata != NULL;
 }
 

Re: [announce] vfs-scale git tree update

[Alex Elder]

On Thu, 2011-01-13 at 11:03 +0800, Ian Kent wrote:
> On Thu, 2011-01-13 at 10:23 +0800, Ian Kent wrote:
> > On Wed, 2011-01-12 at 14:11 -0600, Alex Elder wrote:
> > > On Wed, 2011-01-12 at 12:15 +0800, Ian Kent wrote:
> > > > On Wed, 2011-01-12 at 11:59 +0800, Ian Kent wrote:
. . .
> > > > Could you try this patch please.
> > > 
> > > OK, sorry for the delay.  I tried the patch.  I applied
> > > it against 4162cf64973df51fc885825bc9ca4d055891c49f,
> > > which is the linus/master branch I had on hand.  This
> > > time I got a different failure due to a null pointer
> > > dereference.  Console capture below.  I can log
> > > in still but the boot sequence never got to the
> > > login prompt on the console as it normally does.
> > 
> > 
> > Sorry, that is rather an obvious mistake on my part.
> > There's a call to d_op->d_revalidate() just below where the dentry
> > operations are set. I'm tempted to just call the revalidate function
> > directly since it is always called anyway. But let me check we've done
> > in the our current of tree autofs patch series first.
> 
> Ha, there is no revalidate in the current not yet merged autofs.
> So I think we just need to work around it.
> 
> Try this and see if it resolves the issue.

This one works.  I am able to boot without
hitting the BUG_ON() in d_set_d_op() and
there is no longer the null pointer dereference
that occurred with the last one.

					-Alex

> autofs4 - set dentry op in ->lookup() only
> 
> From: Ian Kent <raven@themaw.net>
> 
> With the introduction of the vfs-scale patch series setting dentry
> operations more than once (or changing them) triggers a BUG_ON().
> Since the two dentry operations used are the same, just set the
> operations in ->lookup() and remove the set in ->symlink() and
> ->mkdir().
> 
> Also, move the d_add() in ->symlink() and ->mkdir() to the end of
> the function.
> ---
> 
>  fs/autofs4/root.c |   40 +++++++---------------------------------
>  1 files changed, 7 insertions(+), 33 deletions(-)
> 
> 
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index 651e4ef..0897706 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -419,12 +419,6 @@ void autofs4_dentry_release(struct dentry *de)
>  	}
>  }
>  
> -/* For dentries of directories in the root dir */
> -static const struct dentry_operations autofs4_root_dentry_operations = {
> -	.d_revalidate	= autofs4_revalidate,
> -	.d_release	= autofs4_dentry_release,
> -};
> -
>  /* For other dentries */
>  static const struct dentry_operations autofs4_dentry_operations = {
>  	.d_revalidate	= autofs4_revalidate,
> @@ -568,19 +562,6 @@ static struct dentry *autofs4_lookup(struct inode *dir, struct dentry *dentry, s
>  		ino = autofs4_dentry_ino(dentry);
>  	} else {
>  		/*
> -		 * Mark the dentry incomplete but don't hash it. We do this
> -		 * to serialize our inode creation operations (symlink and
> -		 * mkdir) which prevents deadlock during the callback to
> -		 * the daemon. Subsequent user space lookups for the same
> -		 * dentry are placed on the wait queue while the daemon
> -		 * itself is allowed passage unresticted so the create
> -		 * operation itself can then hash the dentry. Finally,
> -		 * we check for the hashed dentry and return the newly
> -		 * hashed dentry.
> -		 */
> -		d_set_d_op(dentry, &autofs4_root_dentry_operations);
> -
> -		/*
>  		 * And we need to ensure that the same dentry is used for
>  		 * all following lookup calls until it is hashed so that
>  		 * the dentry flags are persistent throughout the request.
> @@ -589,6 +570,8 @@ static struct dentry *autofs4_lookup(struct inode *dir, struct dentry *dentry, s
>  		if (!ino)
>  			return ERR_PTR(-ENOMEM);
>  
> +		d_set_d_op(dentry, &autofs4_dentry_operations);
> +
>  		dentry->d_fsdata = ino;
>  		ino->dentry = dentry;
>  
> @@ -714,12 +697,6 @@ static int autofs4_dir_symlink(struct inode *dir,
>  			kfree(ino);
>  		return -ENOMEM;
>  	}
> -	d_add(dentry, inode);
> -
> -	if (dir == dir->i_sb->s_root->d_inode)
> -		d_set_d_op(dentry, &autofs4_root_dentry_operations);
> -	else
> -		d_set_d_op(dentry, &autofs4_dentry_operations);
>  
>  	dentry->d_fsdata = ino;
>  	ino->dentry = dget(dentry);
> @@ -732,6 +709,8 @@ static int autofs4_dir_symlink(struct inode *dir,
>  	ino->u.symlink = cp;
>  	dir->i_mtime = CURRENT_TIME;
>  
> +	d_add(dentry, inode);
> +
>  	return 0;
>  }
>  
> @@ -849,12 +828,6 @@ static int autofs4_dir_mkdir(struct inode *dir, struct dentry *dentry, int mode)
>  			kfree(ino);
>  		return -ENOMEM;
>  	}
> -	d_add(dentry, inode);
> -
> -	if (dir == dir->i_sb->s_root->d_inode)
> -		d_set_d_op(dentry, &autofs4_root_dentry_operations);
> -	else
> -		d_set_d_op(dentry, &autofs4_dentry_operations);
>  
>  	dentry->d_fsdata = ino;
>  	ino->dentry = dget(dentry);
> @@ -866,6 +839,8 @@ static int autofs4_dir_mkdir(struct inode *dir, struct dentry *dentry, int mode)
>  	inc_nlink(dir);
>  	dir->i_mtime = CURRENT_TIME;
>  
> +	d_add(dentry, inode);
> +
>  	return 0;
>  }
>  
> @@ -944,8 +919,7 @@ static inline int autofs4_ask_umount(struct vfsmount *mnt, int __user *p)
>  int is_autofs4_dentry(struct dentry *dentry)
>  {
>  	return dentry && dentry->d_inode &&
> -		(dentry->d_op == &autofs4_root_dentry_operations ||
> -		 dentry->d_op == &autofs4_dentry_operations) &&
> +		(dentry->d_op == &autofs4_dentry_operations) &&
>  		dentry->d_fsdata != NULL;
>  }
>  
> 
> 

Re: [announce] vfs-scale git tree update

[Aneesh Kumar K. V]

On Wed, 12 Jan 2011 11:59:36 +0800, Ian Kent <raven@themaw.net> wrote:
> On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
> > On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> > > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> > > >
> > > > FYI, when using this code, as merged by Linus, I hit the
> > > > BUG_ON() at the beginning of d_set_d_op() when it's called
> > > > by autofs4_dir_mkdir().  I managed to work around it by
> > > > just commenting out those BUG_ON() calls but it's something
> > > > that ought to get addressed properly.
> > > 
> > > Yeah, removing the BUG_ON() isn't the right thing to do - it means
> > > that autofs4 is obviously setting the dentry ops twice for the same
> > > dentry.
> > > 
> > > Possibly the thing could be relaxed to allow setting the _same_ d_op
> > > pointer, ie do something like
> > > 
> > >    if (dentry->d_op == op)
> > >       return;
> > > 
> > > at the top of that function. But looking at it, I don't think that
> > > fixes the autofs4 issue.
> > 
> > That's easy enough, but it seems everybody else ensures
> > this gets done just once per dentry, and it would be nice
> > to preserve that "tightness" if possible.
> > 
> > > The fact that autofs4 does "d_add()" before it sets the d_ops (or
> > > other dentry state, for that matter) looks a bit scary. To me that
> > > smells like it might get a  dentry lookup hit before it's actually
> > > fully done.
> > 
> > Agreed.
> 
> Isn't the parent i_mutex held during mkdir()?
> Still the order can be changed, of course.
> 
> > 
> > > Does it make any difference if you move the various d_add() calls down
> > > to the end of the functions to when the "dentry" has really been
> > > instantiated?
> > 
> > Looking at it quickly, I don't think that would matter for
> > the case at hand.  I.e., that might be safer but it doesn't
> > address the fact that these fields are getting initialized
> > multiple times.
> 
> Yeah, a hangover from changes done over time.
> Not setting the dentry op in ->lookup() should fix this.
> 

for 9p I did the other way round. lookup now set the dentry op for both
negative and positive dentries and rest of the place we dropped
d_set_d_op (b8b80cf37c7f0e32729262f805bc0fa81c3e9d12 have the details)

-aneesh

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Wed, 2011-01-12 at 10:19 +0530, Aneesh Kumar K. V wrote:
> On Wed, 12 Jan 2011 11:59:36 +0800, Ian Kent <raven@themaw.net> wrote:
> > On Tue, 2011-01-11 at 11:57 -0600, Alex Elder wrote:
> > > On Tue, 2011-01-11 at 08:51 -0800, Linus Torvalds wrote:
> > > > On Tue, Jan 11, 2011 at 8:34 AM, Alex Elder <aelder@sgi.com> wrote:
> > > > >
> > > > > FYI, when using this code, as merged by Linus, I hit the
> > > > > BUG_ON() at the beginning of d_set_d_op() when it's called
> > > > > by autofs4_dir_mkdir().  I managed to work around it by
> > > > > just commenting out those BUG_ON() calls but it's something
> > > > > that ought to get addressed properly.
> > > > 
> > > > Yeah, removing the BUG_ON() isn't the right thing to do - it means
> > > > that autofs4 is obviously setting the dentry ops twice for the same
> > > > dentry.
> > > > 
> > > > Possibly the thing could be relaxed to allow setting the _same_ d_op
> > > > pointer, ie do something like
> > > > 
> > > >    if (dentry->d_op == op)
> > > >       return;
> > > > 
> > > > at the top of that function. But looking at it, I don't think that
> > > > fixes the autofs4 issue.
> > > 
> > > That's easy enough, but it seems everybody else ensures
> > > this gets done just once per dentry, and it would be nice
> > > to preserve that "tightness" if possible.
> > > 
> > > > The fact that autofs4 does "d_add()" before it sets the d_ops (or
> > > > other dentry state, for that matter) looks a bit scary. To me that
> > > > smells like it might get a  dentry lookup hit before it's actually
> > > > fully done.
> > > 
> > > Agreed.
> > 
> > Isn't the parent i_mutex held during mkdir()?
> > Still the order can be changed, of course.
> > 
> > > 
> > > > Does it make any difference if you move the various d_add() calls down
> > > > to the end of the functions to when the "dentry" has really been
> > > > instantiated?
> > > 
> > > Looking at it quickly, I don't think that would matter for
> > > the case at hand.  I.e., that might be safer but it doesn't
> > > address the fact that these fields are getting initialized
> > > multiple times.
> > 
> > Yeah, a hangover from changes done over time.
> > Not setting the dentry op in ->lookup() should fix this.
> > 
> 
> for 9p I did the other way round. lookup now set the dentry op for both
> negative and positive dentries and rest of the place we dropped
> d_set_d_op (b8b80cf37c7f0e32729262f805bc0fa81c3e9d12 have the details)

Sadly I can't do that.

For now I need to avoid calls to ->d_revalidate() as much as possible to
reduce a potential deadlock and have access to the flags of the negative
dentry (during create) for the purpose of blocking concurrent walks.

But, if all goes well, later changes will see the autofs
->d_revalidate() gone and consequently the potential deadlock gone as
well.

Ian

Re: [announce] vfs-scale git tree update

[Nick Piggin]

On Wed, Jan 12, 2011 at 4:01 PM, Ian Kent <raven@themaw.net> wrote:
> On Wed, 2011-01-12 at 10:19 +0530, Aneesh Kumar K. V wrote:
>> for 9p I did the other way round. lookup now set the dentry op for both
>> negative and positive dentries and rest of the place we dropped
>> d_set_d_op (b8b80cf37c7f0e32729262f805bc0fa81c3e9d12 have the details)
>
> Sadly I can't do that.
>
> For now I need to avoid calls to ->d_revalidate() as much as possible to
> reduce a potential deadlock and have access to the flags of the negative
> dentry (during create) for the purpose of blocking concurrent walks.

What prevents your d_revalidate from just checking for negative dentry?

Re: [announce] vfs-scale git tree update

[Ian Kent]

On Thu, 2011-01-13 at 11:58 +1100, Nick Piggin wrote:
> On Wed, Jan 12, 2011 at 4:01 PM, Ian Kent <raven@themaw.net> wrote:
> > On Wed, 2011-01-12 at 10:19 +0530, Aneesh Kumar K. V wrote:
> >> for 9p I did the other way round. lookup now set the dentry op for both
> >> negative and positive dentries and rest of the place we dropped
> >> d_set_d_op (b8b80cf37c7f0e32729262f805bc0fa81c3e9d12 have the details)
> >
> > Sadly I can't do that.
> >
> > For now I need to avoid calls to ->d_revalidate() as much as possible to
> > reduce a potential deadlock and have access to the flags of the negative
> > dentry (during create) for the purpose of blocking concurrent walks.
> 
> What prevents your d_revalidate from just checking for negative dentry?

Whether the dentry is negative or not doesn't change the need to block
walks which introduces the possibility of blocking while holding the
parent i_mutex, since it can't be released in revalidate.