lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Tue, 7 Jul 2015 12:19:48 -0700
From:	Andiry Xu <andiry@...il.com>
To:	Matthew Wilcox <willy@...ux.intel.com>,
	Linux MM <linux-mm@...ck.org>, linux-kernel@...r.kernel.org
Cc:	Andiry Xu <andiry.xu@...il.com>
Subject: Filebench failure on ramdisk with Ext4-DAX

Hi,

I am running into failures when run filebench on ramdisk(/dev/ram0)
with Ext4-DAX.
The kernel version is 4.0, and I also verified it occurs on 4.2-rc1.

The issue reproduction steps:

// Set ramdisk size to 2GB
# mkfs.ext4 /dev/ram0
# mount -o dax /dev/ram0 /mnt/ramdisk
# filebench
filebench> load fileserver
filebench> set $dir=/mnt/ramdisk
filebench> run 30

And filebench fails in a few seconds like this:

8163: 22.992: Failed to pre-allocate file
/mnt/ramdisk/bigfileset/00000001/00000006/00000001/00000024/00000005/00000002/00000006:
No such file or directory on line 128
 8163: 22.992: Failed to create filesets on line 128

Or like this:

8141: 16.372: Failed to write 51967 bytes on fd 23: Success
 8151: 16.372: Failed to write 136735 bytes on fd 18: Success
 8148: 16.372: Failed to write 123317 bytes on fd 31: Success
 8141: 16.381: filereaderthread-36: flowop wrtfile1-1 failed
 8151: 16.381: filereaderthread-46: flowop wrtfile1-1 failed
 8148: 16.381: filereaderthread-43: flowop wrtfile1-1 failed
 8098: 16.521: Run took 1 seconds...
 8098: 16.521: NO VALID RESULTS! Filebench run terminated prematurely on line 65
 8098: 16.521: Shutting down processes

Sometimes it succeeds, but the chance is low. The failure rate is 80%+.

Note:
The issues does not occur with normal Ext4.
The issues does not occur with Ext4-DAX on pmem driver (from 01org/prd).

The only significant difference between brd.c and pmem.c is that brd.c
uses alloc_page() and pmem.c reserved memory range and uses ioremap()
to get virtual address. I assume that the memcpy
operation(copy_from/to_user) directly between user buffer and page by
alloc_page() does not work correctly somehow. I wonder if this is a
bug? If it is, how to fix it? Thanks.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ