utsaslab / winefs Goto Github PK

WineFS (SOSP 21): a huge-page aware file system for persistent memory

Makefile 0.28% C 95.78% M4 0.01% C++ 1.76% Roff 0.02% Shell 0.27% Yacc 0.02% Lex 0.01% Filebench WML 0.01% Go 0.01% Assembly 1.25% Perl 0.15% Awk 0.01% Python 0.41% sed 0.01% UnrealScript 0.01% SmPL 0.02% Gherkin 0.01% XS 0.01% Raku 0.01%

file-system persistent-memory

winefs's People

Contributors

Stargazers

Watchers

Forkers

potatogim paulwedeck

winefs's Issues

"sched_setaffinity" [fs/winefs/winefs.ko] undefined!

Hello!
I'd like to dynamically load WineFS, thus I ran the command make menuconfig and modified the * in the option box of DuoFS to M after running cp CONFIG_WINEFS .config and make olddefconfig.
However, when I compiled and installed the Linux kernel 5.1 in Linux-5.1/ directory, the error like this occurs:

ERROR: "sched_setaffinity" [fs/winefs/winefs.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1266: recipe for target 'modules' failed
make: *** [modules] Error 2

Here are the figures showing that I have modified the * in the option box of DuoFS to M in menuconfig.
If I want to dynamically load WineFS instead of build it into the kernel, how should I modify the CONFIG_WINEFS or menuconfig?
Looking forward to your reply!
Thanks!

Bugs in the extended attributes mechanism

Hello,
I discovered multiple questionable to bugged code places in xattr.c:

If a directory gets the file_type flag due to its content, the flag is only visible if a listxattr has been executed before the getxattr call.
An implicit file_type flag set by listxattr or getxattr persists even if the condition is no longer true. This even happens if the file system is mounted as read-only.
The setxattr handler does not use a transaction for its data. Therefore, crash states are possible where the parent directory has an implicit flag but the file doesn't and vice versa.
For some crash states, getxattr even fails.

Further, pmfs_new_data_blocks sets the huge_aligned_file flag even if this part of the inode is not part of them transaction.
Therefore, crash states are possible where the overall operation succeeded but the flag (and therefore the implicit) attribute is not set and vice versa.
While inspecting the code, I could only prove that it was necessary for the fallocate syscall to include the whole inode in the transaction.
I assume that there are more places but I have not yet found them.

Write may not be atomic with respect to crashes in strict mode

Hi Rohan,

I think I've found a situation where writes may not occur atomically with respect to crashes even in strict mode. Here are the steps to reproduce the issue:

Add the following at line 809 in xip.c:

if (count == 1024) {
	return written;
}

This will emulate a crash occuring after calling __pmfs_xip_file_write() but before committing the transaction when performing a write of 1024 bytes. The bug requires two writes to manifest, so making it conditional on the write size will make sure we don't emulate the crash too early.
2. Mount WineFS with mount -t winefs -o init,strict /dev/pmem0 /mnt/pmem.
3. Run the following program: test6.zip. This just creates a file /mnt/pmem/file0, writes 4096 bytes of 'a' to it, then overwrites the first 1024 bytes with 'b'.
4. Use dd to copy out the contents of /dev/pmem0 to a separate file, unmount WineFS, recopy the contents of the file, and remount. This ensures that we go through recovery code.

After doing these steps, when I do cat /mnt/pmem/file0, I see that the first 1024 bytes have been overwritten with 'b'. This seems like incorrect behavior, since WineFS is being used in strict mode and the transaction for the write was not committed before the crash. I would expect the file to still be all 'a's.

Let me know what you think. Thanks!

Possible bug in __pmfs_xip_file_write

Steps to reproduce:

Create a new file that allocates all available memory (fallocate -l <large number> <myfile>). I tried 100000000 for a 16MB partition.
Try to append data to the file (echo abcd >> <myfile>)

The second command does not terminate.
The reason is that the write syscall always returns 0 if the allocation fails.
However, it should return an error if two successive writes fails[1].
Many programs like echo (probably a shell builtin but details) will infinitely retry this operation.
This bug is not dangerous but mostly annoying and should be fixed in my opinion.

I think the underlying issue is that pmfs_find_and_alloc_blocks and __pmfs_xip_file_write (for pmfs_get_xip_mem) does not properly propagate errors

[1]: The last sentence is the most relevant one(write(2)):

Note that a successful write() may transfer fewer than count bytes. Such partial writes can occur for various reasons; for example, because there was insufficient space on the disk device to write all of the requested bytes, or because a blocked write() to a socket, pipe, or similar was interrupted by a signal handler after it had transferred some, but before it had transferred all of the requested bytes. In the event of a partial write, the caller can make another write() call to transfer the remaining bytes. The subsequent call will either transfer further bytes or may result in an error (e.g., if the disk is now full).

Potential crash consistency bug in unlink

Hello,
I discovered a similar bug to #20 but in the unlink operation.
If unlink fails after the inode has been written to the truncate list, the truncate list recovery code will "truncate" the file to its former size.
During this operation, it updates the file timestamp.

I think this is invalid because this is neither the original nor the intended final state.
My fix works by only truncating the file if the new size is different from the old size.

Possible crash consistency issue with truncate using multiple file descriptors

Hi Rohan,

I think I've found a new crash consistency issue in WineFS that occurs if multiple file descriptors are used to modify a file and we crash while increasing the file's size using truncate. The bug is a bit complicated and unfortunately I don't have a good way to replicate it outside of my testing infrastructure and don't fully understand the root cause yet, so let me know if anything doesn't make sense. I'm running WineFS in strict mode; I don't know if this occurs in relaxed mode as well.

Suppose we have a program that performs the following operations:

1. create file0
2. fallocate file0 in FALLOC_FL_KEEP_SIZE mode, offset 0x4ce0, len 0x1 
3. write 1 byte to file0
4. ftruncate file0 to 1 byte
5. write 1 byte to file0
6. ftruncate file0 to 64 bytes

The workload is a bit strange (it was generated by our fuzzer) but I've minimized it as much as I can without removing the ability to reproduce the issue.

If we open a file descriptor on line 1 and use it for the rest of the operations, everything works as expected. However, suppose we open a new file descriptor for file0 between lines 2 and 3 and use it for the write and ftruncate on lines 3 and 4, then open another one betwen lines 4 and 5 and use it for the final two operations (as in this program: contenthash-test.zip).

Now, let's say that we crash after the flush on line 2091 of inode.c (flushing the head of the truncate list in pmfs_truncate_add()) goes through and that data becomes durable when performing the second ftruncate(). When the file system is re-mounted and runs recovery, it will recover the truncate list and replay the truncate operation on the truncated inode. During normal/non-crashing execution, the truncate operation causes the extra bytes to be zeroed out, but it seems that this step is skipped here during recovery, and the recovered file can end up with some random garbage in it.

I haven't yet narrowed down a root cause for this; truncation during normal execution vs. recovery use mostly the same code, and I haven't had the opportunity to dig into where things differ. I suspect right now that the use of multiple file descriptors causes some weird regular-execution behavior where the persistent inode might not look the same as it would if we just used 1 file descriptor, so recovery goes a bit differently, but I'm not sure.

Let me know if this makes sense or you have any ideas about what might be going on. I'll keep looking into this issue as well.

Potential bug in the truncate list

Hello,
I discovered a potential bug in the truncate mechanism.
If the system crashes while an entry is in the truncate list, the operation is repeated during recovery.
During this repeated truncate operation, the inode timestamps are set to the current time and not the time when the operation occurred.
Therefore, the "recovered" state is neither the original nor the intended final state which imo is invalid behavior for a file system and should be addressed.

One fix would be to add the new mtime and ctime of the inode to the truncate list which is then recovered.
My implementation also uses a marker field to distinguish between the old and new version of the truncate list entries.

Possible crash consistency bug with write()

Hi Rohan,

I've found a potential crash consistency bug in WineFS that occurs during a write() call. We found the same issue in PMFS (see here: NVSL/PMFS-new#8) and it appears to be present in WineFS as well.

The issue is pretty much exactly the same as the linked PMFS report, but I'll describe it again here. I found it in WineFS's strict mode. Basically, when WineFS uses pmfs_xip_cow_file_write() to perform a write to a page that has already been allocated to a file, it uses pmfs_file_write_fast() to perform the data write and update the file's size and last-modified time. There is a call to pmfs_flush_buffer() at the end of pmfs_file_write_fast() to flush the size and time updates, but it is not followed by a store fence. So, it's possible for the write() call to complete and for another system call to begin and potentially make some new durable writes before the updated file size is durable. Ensuring that there is a fence after this flush fixes the problem.

Would this be considered a bug in WineFS? It seems to violate the synchronous system call guarantee made by the strict mode.

Thanks!

Possible crash consistency bug in the fast write path

Hello,
there is another place where cmpxchg is used to "atomically" set 16 bytes (see #9).
This is in the fast write path when appending a file.
In this case, the file length and file timestamps are updated together.
Crash states are possible where the file data has been updated but not the timestamps.
This is obviously just a minor bug but should still be addressed.

Currently, this cannot be realized atomically.
For the strict mode, I propose to just disable this half of the fast write path.
For the relaxed mode, I propose to swap the order, so that the timestamp might be updated without the new file length/data but not vice-versa.

Kernel bug when truncating file

Hi Rohan,

I've come across a bug in WineFS that occurs when a file is truncated. I'm running WineFS in a QEMU/KVM virtual machine with 4 cores, 8GB DRAM, and 128MB emulated PM.

The steps to reproduce the issue are:

Mount WineFS at /mnt/pmem using mount -t winefs -o init,strict /dev/pmem0 /mnt/pmem
Run this program: test5.zip which creates a file and performs some writes to it with multiple file descriptors, then truncates it

While truncating, the kernel appears to hit the BUG_ON on line 544 of inode.c. This is the output I get:

[   72.575926] kernel BUG at fs/winefs/inode.c:547!
[   72.578380] invalid opcode: 0000 [#1] SMP KASAN
[   72.580638] CPU: 2 PID: 390 Comm: a.out Tainted: G            E     5.1.0+ #445
[   72.584938] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[   72.589759] RIP: 0010:pmfs_setsize+0xf53/0x146b [winefs]
[   72.592559] Code: e0 48 c7 c7 e0 4c 4c a0 e8 19 10 d1 e0 c7 85 28 ff ff ff 00 00 00 00 48 83 bd 18 ff ff ff 00 0f f
[   72.603064] RSP: 0018:ffff8880b8fb7b08 EFLAGS: 00010293
[   72.606821] RAX: ffff8880b3835b00 RBX: 0000000061ac0d4b RCX: ffffffffa04a109d
[   72.611344] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff888111b1f600
[   72.615227] RBP: ffff8880b8fb7c58 R08: ffffed1022363ec1 R09: ffffed1022363ec1
[   72.619640] R10: 0000000000000008 R11: ffffed1022363ec0 R12: ffff8880b236f930
[   72.623865] R13: 1ffff110171f6f71 R14: ffff888101200480 R15: ffff8880b236f980
[   72.627702] FS:  00007f9021616b80(0000) GS:ffff888111b00000(0000) knlGS:0000000000000000
[   72.632041] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   72.635151] CR2: 00007f902089d6e0 CR3: 00000000b89b8000 CR4: 00000000000006a0
[   72.639166] Call Trace:
[   72.640636]  ? pmfs_truncate_add+0x8db/0x8db [winefs]
[   72.643861]  ? pmfs_evict_inode+0x1840/0x1840 [winefs]
[   72.646701]  ? inode_newsize_ok+0x91/0xe0
[   72.648933]  pmfs_notify_change+0x58e/0xb22 [winefs]
[   72.651657]  ? pmfs_new_inode+0x122c/0x122c [winefs]
[   72.654125]  ? evm_inode_setattr+0x3f/0xd0
[   72.656378]  ? pmfs_new_inode+0x122c/0x122c [winefs]
[   72.659077]  notify_change+0x5ad/0x7b0
[   72.660928]  do_truncate+0x112/0x1a0
[   72.662787]  ? do_truncate+0x112/0x1a0
[   72.664656]  ? file_open_root+0x330/0x330
[   72.666838]  ? vfs_write+0x16d/0x2b0
[   72.668937]  ? apparmor_path_truncate+0x26/0x30
[   72.671686]  do_sys_ftruncate+0x1f5/0x270
[   72.674242]  __x64_sys_ftruncate+0x3b/0x40
[   72.676283]  do_syscall_64+0x7d/0x1b0
[   72.678228]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   72.680770] RIP: 0033:0x7f90208a4ec7
[   72.682579] Code: 73 01 c3 48 8b 0d d1 5f 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 8
[   72.691903] RSP: 002b:00007ffc5a126c58 EFLAGS: 00000202 ORIG_RAX: 000000000000004d
[   72.695599] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f90208a4ec7
[   72.699173] RDX: 0000000000008000 RSI: 0000000000000001 RDI: 0000000000000004
[   72.703008] RBP: 00007ffc5a12ec70 R08: 00007f90213fb960 R09: 00007f90213f0740
[   72.706669] R10: 00000000000000b4 R11: 0000000000000202 R12: 000056250a98d850
[   72.710460] R13: 00007ffc5a12ed50 R14: 0000000000000000 R15: 0000000000000000
[   72.714111] Modules linked in: winefs(E) bochs_drm ttm drm_kms_helper drm ppdev psmouse dax_pmem_compat device_daxs
[   72.728023] ---[ end trace 4b383b502e0a168f ]---
[   72.730621] RIP: 0010:pmfs_setsize+0xf53/0x146b [winefs]
[   72.734011] Code: e0 48 c7 c7 e0 4c 4c a0 e8 19 10 d1 e0 c7 85 28 ff ff ff 00 00 00 00 48 83 bd 18 ff ff ff 00 0f f
[   72.743861] RSP: 0018:ffff8880b8fb7b08 EFLAGS: 00010293
[   72.747017] RAX: ffff8880b3835b00 RBX: 0000000061ac0d4b RCX: ffffffffa04a109d
[   72.751063] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff888111b1f600
[   72.755958] RBP: ffff8880b8fb7c58 R08: ffffed1022363ec1 R09: ffffed1022363ec1
[   72.762441] R10: 0000000000000008 R11: ffffed1022363ec0 R12: ffff8880b236f930
[   72.766497] R13: 1ffff110171f6f71 R14: ffff888101200480 R15: ffff8880b236f980
[   72.770804] FS:  00007f9021616b80(0000) GS:ffff888111b00000(0000) knlGS:0000000000000000
[   72.775760] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   72.779157] CR2: 00007f902089d6e0 CR3: 00000000b89b8000 CR4: 00000000000006a0
Segmentation fault

Fast write path timestamp bug

Hello,
I discovered another bug in the fast write path.
The bug occurs when modifying existing file contents if the region does not cross page bounds and the file system is in relaxed mode.
In this case, the file timestamp is only written after the data.
Therefore, crash states are possible where the data has been modified but the timestamp stays the same.

I think the most reasonable way to fix this is to move the timestamp update before the data update.
In this case, it is possible that the file is unmodified but the timestamp has been updated.
However, I think a too young timestamp is better than a too old one.
Otherwise, we could just permanently disable the fast write path but I think this is somewhat of an overreaction.

Possible crash consistency issue with write

NOTE: this original bug description is incorrect - see my comment below for the actual description :)

Hi Rohan,

I've found a potential crash consistency issue in WineFS that occurs if the system crashes while truncating a file. Here are steps to reproduce it:

Simulate a crash in WineFS by adding two return statements to inode.c in the following locations. This will force the system call to exit early, simulating a crash at that point.
- after the call to PERSISTENT_BARRIER() on line 2079
- immediately after the call to pmfs_truncate_add() on line 2192
Mount a fresh instance of WineFS at /mnt/pmem. I am running WineFS in strict mode; I have not checked if this behavior occurs in relaxed mode.
Run a program that creates a new file in WineFS, writes 1 byte to it, writes 1024 bytes to it, then truncates it to a larger size (I'm doing 1494, which was chosen randomly by a fuzzer; I don't think the actual number matters). I have attached the program I am using: test3.zip

After running this program, I would expect the file to either have size 1024 or 1494, but running stat on the file says that it is 1025 bytes. I plan to look into the root cause of this issue soon and will add more info once I have an idea of what might be causing this.

Thanks!

Possible bug in pmfs_increase_btree_height

Steps to reproduce:

Allocate all available memory of a WineFS partition to one file (fallocate -l <large number> <myfile>). I tried 100000000 for a 16MB partition.
Now create a new file and allocate 4097 bytes to it (fallocate -l 4097 <second file>)

This should lead to the fallocate process getting killed and this error message in the kernel log "BUG: unable to handle kernel NULL pointer dereference at 0000000000000000".

I think the issue is that pmfs_increase_btree_height fails due to lack of memory but returns 0 (no error) anyways.
The subsequent allocation attempt tries to read from the inner tree node which is a null block which results in this error.

Segmentation fault when creating 5 files on 4 cores

Hi Rohan,

I'm running WineFS on a QEMU/KVM virtual machine with 4 CPUs, 32GB RAM, and 4GB of emulated persistent memory, running Ubuntu 20.04 and Linux 5.1.0+ with KASAN enabled. I'm finding that when I try to create 5 files or directories on a clean version of WineFS, WineFS crashes with a segmentation fault when attempting to create the 5th one. The crash appears to happen around line 1813 of inode.c, where the number of CPUs is used to calculate an ID for an inode map; I'm wondering if this computation doesn't work correctly on 4 cores? I tried creating a bunch of files on a VM with the same setup, but with 6 cores instead of 4, and didn't run into any problems. This behavior occurs in both strict and relaxed mode.

Here is the output I get upon trying to create a 5th file or directory:

[   34.687098] ==================================================================
[   34.688911] BUG: KASAN: slab-out-of-bounds in mutex_lock+0x85/0xe0
[   34.690429] Write of size 8 at addr ffff8887f8254100 by task mkdir/392
[   34.692034] 
[   34.692436] CPU: 3 PID: 392 Comm: mkdir Tainted: G            E     5.1.0+ #3
[   34.694170] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[   34.696371] Call Trace:
[   34.696987]  dump_stack+0x98/0xe4
[   34.697822]  ? mutex_lock+0x85/0xe0
[   34.698653]  print_address_description+0x71/0x239
[   34.699409]  ? mutex_lock+0x85/0xe0
[   34.699984]  ? mutex_lock+0x85/0xe0
[   34.700551]  kasan_report.cold.3+0x1b/0x3e
[   34.701210]  ? mutex_lock+0x85/0xe0
[   34.701780]  check_memory_region+0x142/0x1c0
[   34.702473]  kasan_check_write+0x18/0x20
[   34.703103]  mutex_lock+0x85/0xe0
[   34.703647]  ? __mutex_lock_slowpath+0x20/0x20
[   34.704363]  ? inode_sb_list_add+0x9c/0xd0
[   34.705024]  ? inode_init_owner+0x13d/0x160
[   34.705731]  pmfs_new_inode+0x670/0x11cd [winefs]
[   34.706502]  ? pmfs_update_inode+0x286/0x286 [winefs]
[   34.707313]  ? d_splice_alias+0x2b9/0x670
[   34.707964]  ? common_perm+0x156/0x350
[   34.708525]  pmfs_mkdir+0x1b6/0x1065 [winefs]
[   34.709006]  ? apparmor_file_receive+0xd0/0xd0
[   34.709500]  ? map_id_up+0xf9/0x1d0
[   34.709893]  ? common_perm_create.constprop.22+0x139/0x190
[   34.710510]  ? pmfs_rename+0x19fb/0x19fb [winefs]
[   34.711038]  ? security_inode_permission+0x84/0xa0
[   34.711583]  vfs_mkdir+0x21e/0x320
[   34.711968]  do_mkdirat+0x1c9/0x210
[   34.712361]  ? __ia32_sys_mknod+0x60/0x60
[   34.712813]  __x64_sys_mkdir+0x40/0x50
[   34.713236]  do_syscall_64+0x81/0x1b0
[   34.713652]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   34.714219] RIP: 0033:0x7fd2537bc687
[   34.714628] Code: 00 b8 ff ff ff ff c3 0f 1f 40 00 48 8b 05 09 d8 2b 00 64 c7 00 5f 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 d7 2b 00 f7 d8 64 89 08
[   34.716689] RSP: 002b:00007fff30f5cb48 EFLAGS: 00000206 ORIG_RAX: 0000000000000053
[   34.717537] RAX: ffffffffffffffda RBX: 00007fff30f5ef11 RCX: 00007fd2537bc687
[   34.718322] RDX: 0000000000000000 RSI: 00000000000001ff RDI: 00007fff30f5ef11
[   34.719070] RBP: 00007fff30f5ccc0 R08: 00000000000001ff R09: 000055c929735e10
[   34.719793] R10: 00000000000001e4 R11: 0000000000000206 R12: 0000000000000000
[   34.720515] R13: 00000000000001ff R14: 00007fff30f5ce58 R15: 0000000000000001
[   34.721240] 
[   34.721405] Allocated by task 386:
[   34.721759]  save_stack+0x43/0xd0
[   34.722107]  __kasan_kmalloc.constprop.13+0xc1/0xd0
[   34.722608]  kasan_kmalloc+0xd/0x10
[   34.722973]  __kmalloc+0x117/0x250
[   34.723334]  kmalloc_array+0x3a/0x4e [winefs]
[   34.723785]  pmfs_fill_super+0x6ae/0x2839 [winefs]
[   34.724275]  mount_bdev+0x223/0x270
[   34.724644]  pmfs_mount+0x3d/0x46 [winefs]
[   34.725063]  legacy_get_tree+0x7a/0xe0
[   34.725446]  vfs_get_tree+0x5a/0x1b0
[   34.725815]  do_mount+0xe61/0x1a00
[   34.726166]  ksys_mount+0xfe/0x110
[   34.726518]  __x64_sys_mount+0x70/0x80
[   34.726907]  do_syscall_64+0x81/0x1b0
[   34.727284]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   34.727804] 
[   34.727965] Freed by task 0:
[   34.728259] (stack is not available)
[   34.728632] 
[   34.728796] The buggy address belongs to the object at ffff8887f8254000
[   34.728796]  which belongs to the cache kmalloc-256 of size 256
[   34.730055] The buggy address is located 0 bytes to the right of
[   34.730055]  256-byte region [ffff8887f8254000, ffff8887f8254100)
[   34.731268] The buggy address belongs to the page:
[   34.731768] page:ffffea001fe09500 count:1 mapcount:0 mapping:ffff888813002fc0 index:0x0 compound_mapcount: 0
[   34.732773] flags: 0x17ffffc0010200(slab|head)
[   34.733240] raw: 0017ffffc0010200 dead000000000100 dead000000000200 ffff888813002fc0
[   34.734033] raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000
[   34.734821] page dumped because: kasan: bad access detected
[   34.735391] 
[   34.735556] Memory state around the buggy address:
[   34.736046]  ffff8887f8254000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   34.736780]  ffff8887f8254080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   34.737515] >ffff8887f8254100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   34.738255]                    ^
[   34.738590]  ffff8887f8254180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   34.739325]  ffff8887f8254200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   34.740064] ==================================================================
[   34.740809] Disabling lock debugging due to kernel taint
[   34.741395] general protection fault: 0000 [#1] SMP KASAN
[   34.741954] CPU: 3 PID: 392 Comm: mkdir Tainted: G    B       E     5.1.0+ #3
[   34.742677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[   34.743617] RIP: 0010:__mutex_lock.isra.6+0x5b5/0x7b0
[   34.744143] Code: be 08 00 00 00 48 89 df e8 38 18 20 ff 48 89 df e8 70 38 20 ff 48 8b 03 48 83 e0 f8 49 89 c4 74 34 48 8d 78 38 e8 4b 37 20 ff <41> 8b 44 24 38 85 c0 0f 84 31 fb ff ff 49 8d 7c 24 3c e8 34 30
[   34.746048] RSP: 0018:ffff8887ed817960 EFLAGS: 00010292
[   34.746589] RAX: 0000000000000000 RBX: ffff8887f8254100 RCX: ffffffff82288d55
[   34.747320] RDX: 0000000000000000 RSI: 0000000000000004 RDI: e3c00106000001b8
[   34.748052] RBP: ffff8887ed817ad0 R08: ffffed10ff04a821 R09: ffffed10ff04a820
[   34.748778] R10: ffffed10ff04a820 R11: 0000000000000007 R12: e3c0010600000180
[   34.749503] R13: ffff8887ec8cc440 R14: e3c0010600000182 R15: ffff8887f3e15500
[   34.750235] FS:  00007fd253ec0f40(0000) GS:ffff888813780000(0000) knlGS:0000000000000000
[   34.751062] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   34.751653] CR2: 00007fd25382babc CR3: 00000007eda62000 CR4: 00000000000006a0
[   34.752380] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   34.753105] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   34.753832] Call Trace:
[   34.754093]  ? printk+0xb0/0xd8
[   34.754421]  ? apic_timer_interrupt+0xa/0x20
[   34.754859]  ? mutex_lock+0x85/0xe0
[   34.755227]  ? ww_mutex_lock_interruptible+0xf0/0xf0
[   34.755743]  ? irq_work_claim+0x4e/0x90
[   34.756144]  ? _raw_spin_unlock_irqrestore+0x19/0x20
[   34.756656]  ? end_report+0x51/0x54
[   34.757028]  ? kasan_report.cold.3+0xe/0x3e
[   34.757463]  ? mutex_lock+0x85/0xe0
[   34.757826]  __mutex_lock_slowpath+0x13/0x20
[   34.758266]  mutex_lock+0xa6/0xe0
[   34.758611]  ? __mutex_lock_slowpath+0x20/0x20
[   34.759075]  ? inode_sb_list_add+0x9c/0xd0
[   34.759500]  ? inode_init_owner+0x13d/0x160
[   34.759950]  pmfs_new_inode+0x670/0x11cd [winefs]
[   34.760442]  ? pmfs_update_inode+0x286/0x286 [winefs]
[   34.760959]  ? d_splice_alias+0x2b9/0x670
[   34.761373]  ? common_perm+0x156/0x350
[   34.761772]  pmfs_mkdir+0x1b6/0x1065 [winefs]
[   34.762224]  ? apparmor_file_receive+0xd0/0xd0
[   34.762687]  ? map_id_up+0xf9/0x1d0
[   34.763048]  ? common_perm_create.constprop.22+0x139/0x190
[   34.763621]  ? pmfs_rename+0x19fb/0x19fb [winefs]
[   34.764108]  ? security_inode_permission+0x84/0xa0
[   34.764599]  vfs_mkdir+0x21e/0x320
[   34.764959]  do_mkdirat+0x1c9/0x210
[   34.765317]  ? __ia32_sys_mknod+0x60/0x60
[   34.765736]  __x64_sys_mkdir+0x40/0x50
[   34.766130]  do_syscall_64+0x81/0x1b0
[   34.766512]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   34.767026] RIP: 0033:0x7fd2537bc687
[   34.767397] Code: 00 b8 ff ff ff ff c3 0f 1f 40 00 48 8b 05 09 d8 2b 00 64 c7 00 5f 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 d7 2b 00 f7 d8 64 89 08
[   34.769299] RSP: 002b:00007fff30f5cb48 EFLAGS: 00000206 ORIG_RAX: 0000000000000053
[   34.770076] RAX: ffffffffffffffda RBX: 00007fff30f5ef11 RCX: 00007fd2537bc687
[   34.770801] RDX: 0000000000000000 RSI: 00000000000001ff RDI: 00007fff30f5ef11
[   34.771539] RBP: 00007fff30f5ccc0 R08: 00000000000001ff R09: 000055c929735e10
[   34.772269] R10: 00000000000001e4 R11: 0000000000000206 R12: 0000000000000000
[   34.772991] R13: 00000000000001ff R14: 00007fff30f5ce58 R15: 0000000000000001
[   34.773712] Modules linked in: winefs(E) bochs_drm(E) ttm(E) drm_kms_helper(E) drm(E) ppdev(E) psmouse(E) dax_pmem_compat(E) device_dax(E) pcspkr(E) fb_sys_fops(E) dax_pmem_core(E) syscopyarea(E) sysfillrect)
[   34.776816] ---[ end trace 96fcab7973ef5990 ]---
[   34.777304] RIP: 0010:__mutex_lock.isra.6+0x5b5/0x7b0
[   34.777833] Code: be 08 00 00 00 48 89 df e8 38 18 20 ff 48 89 df e8 70 38 20 ff 48 8b 03 48 83 e0 f8 49 89 c4 74 34 48 8d 78 38 e8 4b 37 20 ff <41> 8b 44 24 38 85 c0 0f 84 31 fb ff ff 49 8d 7c 24 3c e8 34 30
[   34.779752] RSP: 0018:ffff8887ed817960 EFLAGS: 00010292
[   34.780289] RAX: 0000000000000000 RBX: ffff8887f8254100 RCX: ffffffff82288d55
[   34.781015] RDX: 0000000000000000 RSI: 0000000000000004 RDI: e3c00106000001b8
[   34.781742] RBP: ffff8887ed817ad0 R08: ffffed10ff04a821 R09: ffffed10ff04a820
[   34.782466] R10: ffffed10ff04a820 R11: 0000000000000007 R12: e3c0010600000180
[   34.783216] R13: ffff8887ec8cc440 R14: e3c0010600000182 R15: ffff8887f3e15500
[   34.783957] FS:  00007fd253ec0f40(0000) GS:ffff888813780000(0000) knlGS:0000000000000000
[   34.784778] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   34.785367] CR2: 00007fd25382babc CR3: 00000007eda62000 CR4: 00000000000006a0
[   34.786094] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   34.786835] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Segmentation fault

utsaslab / winefs Goto Github PK

winefs's People

Contributors

Stargazers

Watchers

Forkers

winefs's Issues

Recommend Projects

Recommend Topics

Recommend Org