Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1315860 > unrolled thread

mm: WARNING in __delete_from_page_cache

Started byDmitry Vyukov <dvyukov@google.com>
First post2016-01-24 11:50 +0100
Last post2016-01-27 19:10 +0100
Articles 10 — 6 participants

Back to article view | Back to linux.kernel

Contents

  mm: WARNING in __delete_from_page_cache Dmitry Vyukov <dvyukov@google.com> - 2016-01-24 11:50 +0100
    Re: mm: WARNING in __delete_from_page_cache "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-01-25 00:10 +0100
      Re: mm: WARNING in __delete_from_page_cache Jan Kara <jack@suse.cz> - 2016-01-25 13:30 +0100
        Re: mm: WARNING in __delete_from_page_cache "Williams, Dan J" <dan.j.williams@intel.com> - 2016-01-26 04:50 +0100
          Re: mm: WARNING in __delete_from_page_cache Jan Kara <jack@suse.cz> - 2016-01-26 09:30 +0100
          Re: mm: WARNING in __delete_from_page_cache Matthew Wilcox <willy@linux.intel.com> - 2016-01-26 14:00 +0100
            Re: mm: WARNING in __delete_from_page_cache Jan Kara <jack@suse.cz> - 2016-01-26 14:40 +0100
              Re: mm: WARNING in __delete_from_page_cache "Williams, Dan J" <dan.j.williams@intel.com> - 2016-01-26 18:00 +0100
    Re: mm: WARNING in __delete_from_page_cache Ross Zwisler <zwisler@gmail.com> - 2016-01-27 19:10 +0100
      Re: mm: WARNING in __delete_from_page_cache Dmitry Vyukov <dvyukov@google.com> - 2016-01-27 19:10 +0100

#1315860 — mm: WARNING in __delete_from_page_cache

FromDmitry Vyukov <dvyukov@google.com>
Date2016-01-24 11:50 +0100
Subjectmm: WARNING in __delete_from_page_cache
Message-ID<qUqp4-3ue-7@gated-at.bofh.it>
Hello,

The following program triggers WARNING in __delete_from_page_cache:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
__delete_from_page_cache+0x9f6/0xb60()
Modules linked in:
CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
 ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
 ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
 [<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
 [<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
 [<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
 [<     inline     >] wp_pfn_shared mm/memory.c:2208
 [<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
 [<     inline     >] handle_pte_fault mm/memory.c:3323
 [<     inline     >] __handle_mm_fault mm/memory.c:3417
 [<ffffffff816ecec3>] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
 [<ffffffff8127eff6>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
 [<ffffffff8127f738>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
 [<ffffffff812705c4>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
 [<ffffffff86338f78>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
 [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---[ end trace dae21e0f85f1f98c ]---


// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <pthread.h>
#include <stdint.h>
#include <string.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <fcntl.h>

int main()
{
  syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul, -1, 0x0ul);
  int fd = syscall(SYS_open, "/dev/ram1", O_RDWR);
  syscall(SYS_mmap, 0x20a31000ul, 0x3000ul, 0x3ul, 0xb011ul, fd, 0x0ul);
  *(uint64_t*)0x20003000 = 1;
  syscall(SYS_write, fd, 0x20003000ul, 0x78ul, 0, 0, 0);
  syscall(SYS_getresuid, 0x20000688ul, 0x200008f2ul, 0x20a31000ul, 0, 0, 0);
  return 0;
}

On commit 30f05309bde49295e02e45c7e615f73aa4e0ccc2.

[toc] | [next] | [standalone]

#1316138

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2016-01-25 00:10 +0100
Message-ID<qUBXc-3rR-3@gated-at.bofh.it>
In reply to#1315860
On Sun, Jan 24, 2016 at 11:48:21AM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers WARNING in __delete_from_page_cache:
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
> __delete_from_page_cache+0x9f6/0xb60()
> Modules linked in:
> CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
>  ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
>  ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
> Call Trace:
>  [<     inline     >] __dump_stack lib/dump_stack.c:15
>  [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>  [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>  [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>  [<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
>  [<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
>  [<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
>  [<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
>  [<     inline     >] wp_pfn_shared mm/memory.c:2208
>  [<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
>  [<     inline     >] handle_pte_fault mm/memory.c:3323
>  [<     inline     >] __handle_mm_fault mm/memory.c:3417
>  [<ffffffff816ecec3>] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
>  [<ffffffff8127eff6>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
>  [<ffffffff8127f738>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
>  [<ffffffff812705c4>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
>  [<ffffffff86338f78>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
>  [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> ---[ end trace dae21e0f85f1f98c ]---
> 
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <pthread.h>
> #include <stdint.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <unistd.h>
> #include <fcntl.h>
> 
> int main()
> {
>   syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul, -1, 0x0ul);
>   int fd = syscall(SYS_open, "/dev/ram1", O_RDWR);
>   syscall(SYS_mmap, 0x20a31000ul, 0x3000ul, 0x3ul, 0xb011ul, fd, 0x0ul);
>   *(uint64_t*)0x20003000 = 1;
>   syscall(SYS_write, fd, 0x20003000ul, 0x78ul, 0, 0, 0);
>   syscall(SYS_getresuid, 0x20000688ul, 0x200008f2ul, 0x20a31000ul, 0, 0, 0);
>   return 0;
> }
> 
> On commit 30f05309bde49295e02e45c7e615f73aa4e0ccc2.

Reduced and human readable test case:

#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

int main()
{
	int fd;
	char *p;

	fd = open("/dev/ram0", O_RDWR);
	p = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
	write(fd, "1", 1);
	*p = 1;
	return 0;
}

Looks like DAX doesn't expect to see something except hole-page in the radix
tree. This expectation is [probably] true for files on DAX-enabled
filesystems, but it seems broken for ramdisks.

Matthew?

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1316614

FromJan Kara <jack@suse.cz>
Date2016-01-25 13:30 +0100
Message-ID<qUOrn-3Og-1@gated-at.bofh.it>
In reply to#1316138
On Mon 25-01-16 01:04:22, Kirill A. Shutemov wrote:
> On Sun, Jan 24, 2016 at 11:48:21AM +0100, Dmitry Vyukov wrote:
> > Hello,
> > 
> > The following program triggers WARNING in __delete_from_page_cache:
> > 
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
> > __delete_from_page_cache+0x9f6/0xb60()
> > Modules linked in:
> > CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >  00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
> >  ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
> >  ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
> > Call Trace:
> >  [<     inline     >] __dump_stack lib/dump_stack.c:15
> >  [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
> >  [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
> >  [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
> >  [<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
> >  [<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
> >  [<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
> >  [<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
> >  [<     inline     >] wp_pfn_shared mm/memory.c:2208
> >  [<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
> >  [<     inline     >] handle_pte_fault mm/memory.c:3323
> >  [<     inline     >] __handle_mm_fault mm/memory.c:3417
> >  [<ffffffff816ecec3>] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
> >  [<ffffffff8127eff6>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
> >  [<ffffffff8127f738>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
> >  [<ffffffff812705c4>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
> >  [<ffffffff86338f78>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
> >  [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
> > arch/x86/entry/entry_64.S:185
> > ---[ end trace dae21e0f85f1f98c ]---
> > 
> > 
> > // autogenerated by syzkaller (http://github.com/google/syzkaller)
> > #include <pthread.h>
> > #include <stdint.h>
> > #include <string.h>
> > #include <sys/syscall.h>
> > #include <unistd.h>
> > #include <fcntl.h>
> > 
> > int main()
> > {
> >   syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul, -1, 0x0ul);
> >   int fd = syscall(SYS_open, "/dev/ram1", O_RDWR);
> >   syscall(SYS_mmap, 0x20a31000ul, 0x3000ul, 0x3ul, 0xb011ul, fd, 0x0ul);
> >   *(uint64_t*)0x20003000 = 1;
> >   syscall(SYS_write, fd, 0x20003000ul, 0x78ul, 0, 0, 0);
> >   syscall(SYS_getresuid, 0x20000688ul, 0x200008f2ul, 0x20a31000ul, 0, 0, 0);
> >   return 0;
> > }
> > 
> > On commit 30f05309bde49295e02e45c7e615f73aa4e0ccc2.
> 
> Reduced and human readable test case:
> 
> #include <fcntl.h>
> #include <unistd.h>
> #include <sys/mman.h>
> 
> int main()
> {
> 	int fd;
> 	char *p;
> 
> 	fd = open("/dev/ram0", O_RDWR);
> 	p = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> 	write(fd, "1", 1);
> 	*p = 1;
> 	return 0;
> }
> 
> Looks like DAX doesn't expect to see something except hole-page in the radix
> tree. This expectation is [probably] true for files on DAX-enabled
> filesystems, but it seems broken for ramdisks.
> 
> Matthew?

Thanks. Despite the huge list of recipients the author of the changes
hasn't been CCed :) I've added Dan to CC since he wrote DAX support for
block devices. It seems somehow the write didn't go through the DAX path
but through the standard page cache write path. Ah, I see, only
file->f_mapping->host has S_DAX set but io_is_direct() which decides
whether DAX or pagecache path should be used for writes uses file->f_inode
which is something different for block devices... 

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[toc] | [prev] | [next] | [standalone]

#1317511

From"Williams, Dan J" <dan.j.williams@intel.com>
Date2016-01-26 04:50 +0100
Message-ID<qV2NH-5Hq-1@gated-at.bofh.it>
In reply to#1316614
On Mon, 2016-01-25 at 13:22 +-0100, Jan Kara wrote:
+AFs-..+AF0-
+AD4- Thanks. Despite the huge list of recipients the author of the changes
+AD4- hasn't been CCed :) I've added Dan to CC since he wrote DAX support
+AD4- for
+AD4- block devices. It seems somehow the write didn't go through the DAX
+AD4- path
+AD4- but through the standard page cache write path. Ah, I see, only
+AD4- file-+AD4-f+AF8-mapping-+AD4-host has S+AF8-DAX set but io+AF8-is+AF8-direct() which decides
+AD4- whether DAX or pagecache path should be used for writes uses file-
+AD4- +AD4-f+AF8-inode
+AD4- which is something different for block devices...+AKA-

Thanks, yes, the following silences the warning for me:

8+ADw------ (git am --scissors)
Subject: fs, block: force direct-I/O for dax-enabled block devices

From: Dan Williams +ADw-dan.j.williams+AEA-intel.com+AD4-

Similar to the file I/O path, re-direct all I/O to the DAX path for I/O
to a block-device special file.

Otherwise, we confuse the DAX code that does not expect to find live
data in the page cache:

+AKAAoACgAKA-------------+AFs- cut here +AF0-------------
+AKAAoACgAKA-WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
+AKAAoACgAKAAXwBf-delete+AF8-from+AF8-page+AF8-cache+-0x9f6/0xb60()
+AKAAoACgAKA-Modules linked in:
+AKAAoACgAKA-CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+- +ACM-276
+AKAAoACgAKA-Hardware name: QEMU Standard PC (i440FX +- PIIX, 1996), BIOS Bochs 01/01/2011
+AKAAoACgAKAAoA-00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
+AKAAoACgAKAAoA-ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
+AKAAoACgAKAAoA-ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
+AKAAoACgAKA-Call Trace:
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- +AF8AXw-dump+AF8-stack lib/dump+AF8-stack.c:15
+AKAAoACgAKAAoABbADw-ffffffff82999e2d+AD4AXQ- dump+AF8-stack+-0x6f/0xa2 lib/dump+AF8-stack.c:50
+AKAAoACgAKAAoABbADw-ffffffff81352089+AD4AXQ- warn+AF8-slowpath+AF8-common+-0xd9/0x140 kernel/panic.c:482
+AKAAoACgAKAAoABbADw-ffffffff813522b9+AD4AXQ- warn+AF8-slowpath+AF8-null+-0x29/0x30 kernel/panic.c:515
+AKAAoACgAKAAoABbADw-ffffffff81658d36+AD4AXQ- +AF8AXw-delete+AF8-from+AF8-page+AF8-cache+-0x9f6/0xb60 mm/filemap.c:217
+AKAAoACgAKAAoABbADw-ffffffff81658fb2+AD4AXQ- delete+AF8-from+AF8-page+AF8-cache+-0x112/0x200 mm/filemap.c:244
+AKAAoACgAKAAoABbADw-ffffffff818af369+AD4AXQ- +AF8AXw-dax+AF8-fault+-0x859/0x1800 fs/dax.c:487
+AKAAoACgAKAAoABbADw-ffffffff8186f4f6+AD4AXQ- blkdev+AF8-dax+AF8-fault+-0x26/0x30 fs/block+AF8-dev.c:1730
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- wp+AF8-pfn+AF8-shared mm/memory.c:2208
+AKAAoACgAKAAoABbADw-ffffffff816e9145+AD4AXQ- do+AF8-wp+AF8-page+-0xc85/0x14f0 mm/memory.c:2307
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- handle+AF8-pte+AF8-fault mm/memory.c:3323
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- +AF8AXw-handle+AF8-mm+AF8-fault mm/memory.c:3417
+AKAAoACgAKAAoABbADw-ffffffff816ecec3+AD4AXQ- handle+AF8-mm+AF8-fault+-0x2483/0x4640 mm/memory.c:3446
+AKAAoACgAKAAoABbADw-ffffffff8127eff6+AD4AXQ- +AF8AXw-do+AF8-page+AF8-fault+-0x376/0x960 arch/x86/mm/fault.c:1238
+AKAAoACgAKAAoABbADw-ffffffff8127f738+AD4AXQ- trace+AF8-do+AF8-page+AF8-fault+-0xe8/0x420 arch/x86/mm/fault.c:1331
+AKAAoACgAKAAoABbADw-ffffffff812705c4+AD4AXQ- do+AF8-async+AF8-page+AF8-fault+-0x14/0xd0 arch/x86/kernel/kvm.c:264
+AKAAoACgAKAAoABbADw-ffffffff86338f78+AD4AXQ- async+AF8-page+AF8-fault+-0x28/0x30 arch/x86/entry/entry+AF8-64.S:986
+AKAAoACgAKAAoABbADw-ffffffff86336c36+AD4AXQ- entry+AF8-SYSCALL+AF8-64+AF8-fastpath+-0x16/0x7a
+AKAAoACgAKA-arch/x86/entry/entry+AF8-64.S:185
+AKAAoACgAKA----+AFs- end trace dae21e0f85f1f98c +AF0----

Cc: Matthew Wilcox +ADw-willy+AEA-linux.intel.com+AD4-
Cc: Ross Zwisler +ADw-ross.zwisler+AEA-linux.intel.com+AD4-
Fixes: 5a023cdba50c (+ACI-block: enable dax for raw block devices+ACI-)
Reported-by: Dmitry Vyukov +ADw-dvyukov+AEA-google.com+AD4-
Reported-by: Kirill A. Shutemov +ADw-kirill+AEA-shutemov.name+AD4-
Suggested-by: Jan Kara +ADw-jack+AEA-suse.cz+AD4-
Signed-off-by: Dan Williams +ADw-dan.j.williams+AEA-intel.com+AD4-
---
+AKA-fs/block+AF8-dev.c+AKAAoACgAKAAoAB8AKAAoACgAKA-5 -----
+AKA-include/linux/fs.h +AHwAoACgAKA-12 +-+-+-+-+-+-+-+-+-+-+--
+AKA-2 files changed, 11 insertions(+-), 6 deletions(-)

diff --git a/fs/block+AF8-dev.c b/fs/block+AF8-dev.c
index 7b9cd49622b1..277008617b2d 100644
--- a/fs/block+AF8-dev.c
+-+-+- b/fs/block+AF8-dev.c
+AEAAQA- -156,11 +-156,6 +AEAAQA- blkdev+AF8-get+AF8-block(struct inode +ACo-inode, sector+AF8-t iblock,
+AKA-	return 0+ADs-
+AKAAfQ-
+AKA-
-static struct inode +ACo-bdev+AF8-file+AF8-inode(struct file +ACo-file)
-+AHs-
-	return file-+AD4-f+AF8-mapping-+AD4-host+ADs-
-+AH0-
-
+AKA-static ssize+AF8-t
+AKA-blkdev+AF8-direct+AF8-IO(struct kiocb +ACo-iocb, struct iov+AF8-iter +ACo-iter, loff+AF8-t offset)
+AKAAew-
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 1a2046275cdf..a4c4314eed48 100644
--- a/include/linux/fs.h
+-+-+- b/include/linux/fs.h
+AEAAQA- -1237,6 +-1237,11 +AEAAQA- static inline struct inode +ACo-file+AF8-inode(const struct file +ACo-f)
+AKA-	return f-+AD4-f+AF8-inode+ADs-
+AKAAfQ-
+AKA-
+-static inline struct inode +ACo-bdev+AF8-file+AF8-inode(struct file +ACo-file)
+-+AHs-
+-	return file-+AD4-f+AF8-mapping-+AD4-host+ADs-
+-+AH0-
+-
+AKA-static inline int locks+AF8-lock+AF8-file+AF8-wait(struct file +ACo-filp, struct file+AF8-lock +ACo-fl)
+AKAAew-
+AKA-	return locks+AF8-lock+AF8-inode+AF8-wait(file+AF8-inode(filp), fl)+ADs-
+AEAAQA- -2907,7 +-2912,12 +AEAAQA- extern void replace+AF8-mount+AF8-options(struct super+AF8-block +ACo-sb, char +ACo-options)+ADs-
+AKA-
+AKA-static inline bool io+AF8-is+AF8-direct(struct file +ACo-filp)
+AKAAew-
-	return (filp-+AD4-f+AF8-flags +ACY- O+AF8-DIRECT) +AHwAfA- IS+AF8-DAX(file+AF8-inode(filp))+ADs-
+-	struct inode +ACo-inode +AD0- file+AF8-inode(filp)+ADs-
+-
+-	if (S+AF8-ISBLK(inode-+AD4-i+AF8-mode))
+-		inode +AD0- bdev+AF8-file+AF8-inode(filp)+ADs-
+-
+-	return (filp-+AD4-f+AF8-flags +ACY- O+AF8-DIRECT) +AHwAfA- IS+AF8-DAX(inode)+ADs-
+AKAAfQ-
+AKA-
+AKA-static inline int iocb+AF8-flags(struct file +ACo-file)

[toc] | [prev] | [next] | [standalone]

#1317623

FromJan Kara <jack@suse.cz>
Date2016-01-26 09:30 +0100
Message-ID<qV7aH-1qe-23@gated-at.bofh.it>
In reply to#1317511
On Tue 26-01-16 03:42:34, Williams, Dan J wrote:
> On Mon, 2016-01-25 at 13:22 +0100, Jan Kara wrote:
> [..]
> > Thanks. Despite the huge list of recipients the author of the changes
> > hasn't been CCed :) I've added Dan to CC since he wrote DAX support
> > for
> > block devices. It seems somehow the write didn't go through the DAX
> > path
> > but through the standard page cache write path. Ah, I see, only
> > file->f_mapping->host has S_DAX set but io_is_direct() which decides
> > whether DAX or pagecache path should be used for writes uses file-
> > >f_inode
> > which is something different for block devices... 
> 
> Thanks, yes, the following silences the warning for me:
> 
> 8<----- (git am --scissors)
> Subject: fs, block: force direct-I/O for dax-enabled block devices
> 
> From: Dan Williams <dan.j.williams@intel.com>
> 
> Similar to the file I/O path, re-direct all I/O to the DAX path for I/O
> to a block-device special file.
> 
> Otherwise, we confuse the DAX code that does not expect to find live
> data in the page cache:
> 
>     ------------[ cut here ]------------
>     WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
>     __delete_from_page_cache+0x9f6/0xb60()
>     Modules linked in:
>     CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
>     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>      00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
>      ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
>      ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
>     Call Trace:
>      [<     inline     >] __dump_stack lib/dump_stack.c:15
>      [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>      [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>      [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>      [<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
>      [<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
>      [<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
>      [<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
>      [<     inline     >] wp_pfn_shared mm/memory.c:2208
>      [<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
>      [<     inline     >] handle_pte_fault mm/memory.c:3323
>      [<     inline     >] __handle_mm_fault mm/memory.c:3417
>      [<ffffffff816ecec3>] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
>      [<ffffffff8127eff6>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
>      [<ffffffff8127f738>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
>      [<ffffffff812705c4>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
>      [<ffffffff86338f78>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
>      [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
>     arch/x86/entry/entry_64.S:185
>     ---[ end trace dae21e0f85f1f98c ]---
> 
> Cc: Matthew Wilcox <willy@linux.intel.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: 5a023cdba50c ("block: enable dax for raw block devices")
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
> Suggested-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

The patch looks good to me. You can add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
> ---
>  fs/block_dev.c     |    5 -----
>  include/linux/fs.h |   12 +++++++++++-
>  2 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 7b9cd49622b1..277008617b2d 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -156,11 +156,6 @@ blkdev_get_block(struct inode *inode, sector_t iblock,
>  	return 0;
>  }
>  
> -static struct inode *bdev_file_inode(struct file *file)
> -{
> -	return file->f_mapping->host;
> -}
> -
>  static ssize_t
>  blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, loff_t offset)
>  {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 1a2046275cdf..a4c4314eed48 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1237,6 +1237,11 @@ static inline struct inode *file_inode(const struct file *f)
>  	return f->f_inode;
>  }
>  
> +static inline struct inode *bdev_file_inode(struct file *file)
> +{
> +	return file->f_mapping->host;
> +}
> +
>  static inline int locks_lock_file_wait(struct file *filp, struct file_lock *fl)
>  {
>  	return locks_lock_inode_wait(file_inode(filp), fl);
> @@ -2907,7 +2912,12 @@ extern void replace_mount_options(struct super_block *sb, char *options);
>  
>  static inline bool io_is_direct(struct file *filp)
>  {
> -	return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
> +	struct inode *inode = file_inode(filp);
> +
> +	if (S_ISBLK(inode->i_mode))
> +		inode = bdev_file_inode(filp);
> +
> +	return (filp->f_flags & O_DIRECT) || IS_DAX(inode);
>  }
>  
>  static inline int iocb_flags(struct file *file)
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[toc] | [prev] | [next] | [standalone]

#1317873

FromMatthew Wilcox <willy@linux.intel.com>
Date2016-01-26 14:00 +0100
Message-ID<qVbo0-4eF-47@gated-at.bofh.it>
In reply to#1317511
On Tue, Jan 26, 2016 at 03:42:34AM +0000, Williams, Dan J wrote:
> @@ -2907,7 +2912,12 @@ extern void replace_mount_options(struct super_block *sb, char *options);
>  
>  static inline bool io_is_direct(struct file *filp)
>  {
> -	return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));

I think this should just be a one-liner:

-	return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
+	return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);

This does the right thing for block device inodes and filesystem inodes.
(see the opening stanzas of __dax_fault for an example).

[toc] | [prev] | [next] | [standalone]

#1317919

FromJan Kara <jack@suse.cz>
Date2016-01-26 14:40 +0100
Message-ID<qVc0G-4LK-19@gated-at.bofh.it>
In reply to#1317873
On Tue 26-01-16 07:54:56, Matthew Wilcox wrote:
> On Tue, Jan 26, 2016 at 03:42:34AM +0000, Williams, Dan J wrote:
> > @@ -2907,7 +2912,12 @@ extern void replace_mount_options(struct super_block *sb, char *options);
> >  
> >  static inline bool io_is_direct(struct file *filp)
> >  {
> > -	return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
> 
> I think this should just be a one-liner:
> 
> -	return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
> +	return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
> 
> This does the right thing for block device inodes and filesystem inodes.
> (see the opening stanzas of __dax_fault for an example).

Ah, right. This looks indeed better.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[toc] | [prev] | [next] | [standalone]

#1318148

From"Williams, Dan J" <dan.j.williams@intel.com>
Date2016-01-26 18:00 +0100
Message-ID<qVf8g-6St-41@gated-at.bofh.it>
In reply to#1317919
On Tue, 2016-01-26 at 14:36 +-0100, Jan Kara wrote:
+AD4- On Tue 26-01-16 07:54:56, Matthew Wilcox wrote:
+AD4- +AD4- On Tue, Jan 26, 2016 at 03:42:34AM +-0000, Williams, Dan J wrote:
+AD4- +AD4- +AD4- +AEAAQA- -2907,7 +-2912,12 +AEAAQA- extern void replace+AF8-mount+AF8-options(struct
+AD4- +AD4- +AD4- super+AF8-block +ACo-sb, char +ACo-options)+ADs-
+AD4- +AD4- +AD4- +AKA-
+AD4- +AD4- +AD4- +AKA-static inline bool io+AF8-is+AF8-direct(struct file +ACo-filp)
+AD4- +AD4- +AD4- +AKAAew-
+AD4- +AD4- +AD4- -	return (filp-+AD4-f+AF8-flags +ACY- O+AF8-DIRECT) +AHwAfA-
+AD4- +AD4- +AD4- IS+AF8-DAX(file+AF8-inode(filp))+ADs-
+AD4- +AD4- 
+AD4- +AD4- I think this should just be a one-liner:
+AD4- +AD4- 
+AD4- +AD4- -	return (filp-+AD4-f+AF8-flags +ACY- O+AF8-DIRECT) +AHwAfA-
+AD4- +AD4- IS+AF8-DAX(file+AF8-inode(filp))+ADs-
+AD4- +AD4- +-	return (filp-+AD4-f+AF8-flags +ACY- O+AF8-DIRECT) +AHwAfA- IS+AF8-DAX(filp-
+AD4- +AD4- +AD4-f+AF8-mapping-+AD4-host)+ADs-
+AD4- +AD4- 
+AD4- +AD4- This does the right thing for block device inodes and filesystem
+AD4- +AD4- inodes.
+AD4- +AD4- (see the opening stanzas of +AF8AXw-dax+AF8-fault for an example).
+AD4- 
+AD4- Ah, right. This looks indeed better.
+AD4- 


Oh, yeah, looks good.

8+ADw----- (git am --scissors)
Subject: fs, block: force direct-I/O for dax-enabled block devices

From: Dan Williams +ADw-dan.j.williams+AEA-intel.com+AD4-

Similar to the file I/O path, re-direct all I/O to the DAX path for I/O
to a block-device special file.+AKAAoA-Both regular files and device special
files can use the common filp-+AD4-f+AF8-mapping-+AD4-host lookup to determing is
DAX is enabled.

Otherwise, we confuse the DAX code that does not expect to find live
data in the page cache:

+AKAAoACgAKA-------------+AFs- cut here +AF0-------------
+AKAAoACgAKA-WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
+AKAAoACgAKAAXwBf-delete+AF8-from+AF8-page+AF8-cache+-0x9f6/0xb60()
+AKAAoACgAKA-Modules linked in:
+AKAAoACgAKA-CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+- +ACM-276
+AKAAoACgAKA-Hardware name: QEMU Standard PC (i440FX +- PIIX, 1996), BIOS Bochs 01/01/2011
+AKAAoACgAKAAoA-00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
+AKAAoACgAKAAoA-ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
+AKAAoACgAKAAoA-ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
+AKAAoACgAKA-Call Trace:
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- +AF8AXw-dump+AF8-stack lib/dump+AF8-stack.c:15
+AKAAoACgAKAAoABbADw-ffffffff82999e2d+AD4AXQ- dump+AF8-stack+-0x6f/0xa2 lib/dump+AF8-stack.c:50
+AKAAoACgAKAAoABbADw-ffffffff81352089+AD4AXQ- warn+AF8-slowpath+AF8-common+-0xd9/0x140 kernel/panic.c:482
+AKAAoACgAKAAoABbADw-ffffffff813522b9+AD4AXQ- warn+AF8-slowpath+AF8-null+-0x29/0x30 kernel/panic.c:515
+AKAAoACgAKAAoABbADw-ffffffff81658d36+AD4AXQ- +AF8AXw-delete+AF8-from+AF8-page+AF8-cache+-0x9f6/0xb60 mm/filemap.c:217
+AKAAoACgAKAAoABbADw-ffffffff81658fb2+AD4AXQ- delete+AF8-from+AF8-page+AF8-cache+-0x112/0x200 mm/filemap.c:244
+AKAAoACgAKAAoABbADw-ffffffff818af369+AD4AXQ- +AF8AXw-dax+AF8-fault+-0x859/0x1800 fs/dax.c:487
+AKAAoACgAKAAoABbADw-ffffffff8186f4f6+AD4AXQ- blkdev+AF8-dax+AF8-fault+-0x26/0x30 fs/block+AF8-dev.c:1730
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- wp+AF8-pfn+AF8-shared mm/memory.c:2208
+AKAAoACgAKAAoABbADw-ffffffff816e9145+AD4AXQ- do+AF8-wp+AF8-page+-0xc85/0x14f0 mm/memory.c:2307
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- handle+AF8-pte+AF8-fault mm/memory.c:3323
+AKAAoACgAKAAoABbADwAoACgAKAAoACg-inline+AKAAoACgAKAAoAA+AF0- +AF8AXw-handle+AF8-mm+AF8-fault mm/memory.c:3417
+AKAAoACgAKAAoABbADw-ffffffff816ecec3+AD4AXQ- handle+AF8-mm+AF8-fault+-0x2483/0x4640 mm/memory.c:3446
+AKAAoACgAKAAoABbADw-ffffffff8127eff6+AD4AXQ- +AF8AXw-do+AF8-page+AF8-fault+-0x376/0x960 arch/x86/mm/fault.c:1238
+AKAAoACgAKAAoABbADw-ffffffff8127f738+AD4AXQ- trace+AF8-do+AF8-page+AF8-fault+-0xe8/0x420 arch/x86/mm/fault.c:1331
+AKAAoACgAKAAoABbADw-ffffffff812705c4+AD4AXQ- do+AF8-async+AF8-page+AF8-fault+-0x14/0xd0 arch/x86/kernel/kvm.c:264
+AKAAoACgAKAAoABbADw-ffffffff86338f78+AD4AXQ- async+AF8-page+AF8-fault+-0x28/0x30 arch/x86/entry/entry+AF8-64.S:986
+AKAAoACgAKAAoABbADw-ffffffff86336c36+AD4AXQ- entry+AF8-SYSCALL+AF8-64+AF8-fastpath+-0x16/0x7a
+AKAAoACgAKA-arch/x86/entry/entry+AF8-64.S:185
+AKAAoACgAKA----+AFs- end trace dae21e0f85f1f98c +AF0----

Cc: Ross Zwisler +ADw-ross.zwisler+AEA-linux.intel.com+AD4-
Fixes: 5a023cdba50c (+ACI-block: enable dax for raw block devices+ACI-)
Reported-by: Dmitry Vyukov +ADw-dvyukov+AEA-google.com+AD4-
Reported-by: Kirill A. Shutemov +ADw-kirill+AEA-shutemov.name+AD4-
Suggested-by: Jan Kara +ADw-jack+AEA-suse.cz+AD4-
Reviewed-by: Jan Kara +ADw-jack+AEA-suse.cz+AD4-
Suggested-by: Matthew Wilcox +ADw-willy+AEA-linux.intel.com+AD4-
Signed-off-by: Dan Williams +ADw-dan.j.williams+AEA-intel.com+AD4-
---
+AKA-include/linux/fs.h +AHwAoACgAKAAoA-2 +--
+AKA-1 file changed, 1 insertion(+-), 1 deletion(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 1a2046275cdf..b10002d4a5f5 100644
--- a/include/linux/fs.h
+-+-+- b/include/linux/fs.h
+AEAAQA- -2907,7 +-2907,7 +AEAAQA- extern void replace+AF8-mount+AF8-options(struct super+AF8-block +ACo-sb, char +ACo-options)+ADs-
+AKA-
+AKA-static inline bool io+AF8-is+AF8-direct(struct file +ACo-filp)
+AKAAew-
-	return (filp-+AD4-f+AF8-flags +ACY- O+AF8-DIRECT) +AHwAfA- IS+AF8-DAX(file+AF8-inode(filp))+ADs-
+-	return (filp-+AD4-f+AF8-flags +ACY- O+AF8-DIRECT) +AHwAfA- IS+AF8-DAX(filp-+AD4-f+AF8-mapping-+AD4-host)+ADs-
+AKAAfQ-
+AKA-
+AKA-static inline int iocb+AF8-flags(struct file +ACo-file)

[toc] | [prev] | [next] | [standalone]

#1319200

FromRoss Zwisler <zwisler@gmail.com>
Date2016-01-27 19:10 +0100
Message-ID<qVCHw-7xR-9@gated-at.bofh.it>
In reply to#1315860
On Sun, Jan 24, 2016 at 3:48 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> The following program triggers WARNING in __delete_from_page_cache:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
> __delete_from_page_cache+0x9f6/0xb60()
> Modules linked in:
> CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
>  ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
>  ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
> Call Trace:
>  [<     inline     >] __dump_stack lib/dump_stack.c:15
>  [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>  [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>  [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>  [<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
>  [<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
>  [<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
>  [<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
>  [<     inline     >] wp_pfn_shared mm/memory.c:2208
>  [<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
>  [<     inline     >] handle_pte_fault mm/memory.c:3323
>  [<     inline     >] __handle_mm_fault mm/memory.c:3417

Having inline functions represented in the stack trace and having file
names with line numbers seems really useful - how did you get this
output?  Is this a feature of some kernel patch applied for syzkaller?

>  [<ffffffff816ecec3>] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
>  [<ffffffff8127eff6>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
>  [<ffffffff8127f738>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
>  [<ffffffff812705c4>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
>  [<ffffffff86338f78>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
>  [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> ---[ end trace dae21e0f85f1f98c ]---
>
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <pthread.h>
> #include <stdint.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <unistd.h>
> #include <fcntl.h>
>
> int main()
> {
>   syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul, -1, 0x0ul);
>   int fd = syscall(SYS_open, "/dev/ram1", O_RDWR);
>   syscall(SYS_mmap, 0x20a31000ul, 0x3000ul, 0x3ul, 0xb011ul, fd, 0x0ul);
>   *(uint64_t*)0x20003000 = 1;
>   syscall(SYS_write, fd, 0x20003000ul, 0x78ul, 0, 0, 0);
>   syscall(SYS_getresuid, 0x20000688ul, 0x200008f2ul, 0x20a31000ul, 0, 0, 0);
>   return 0;
> }
>
> On commit 30f05309bde49295e02e45c7e615f73aa4e0ccc2.

[toc] | [prev] | [next] | [standalone]

#1319205

FromDmitry Vyukov <dvyukov@google.com>
Date2016-01-27 19:10 +0100
Message-ID<qVCHx-7xR-27@gated-at.bofh.it>
In reply to#1319200
On Wed, Jan 27, 2016 at 7:02 PM, Ross Zwisler <zwisler@gmail.com> wrote:
> On Sun, Jan 24, 2016 at 3:48 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> Hello,
>>
>> The following program triggers WARNING in __delete_from_page_cache:
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
>> __delete_from_page_cache+0x9f6/0xb60()
>> Modules linked in:
>> CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>  00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
>>  ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
>>  ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
>> Call Trace:
>>  [<     inline     >] __dump_stack lib/dump_stack.c:15
>>  [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>>  [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>>  [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>>  [<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
>>  [<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
>>  [<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
>>  [<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
>>  [<     inline     >] wp_pfn_shared mm/memory.c:2208
>>  [<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
>>  [<     inline     >] handle_pte_fault mm/memory.c:3323
>>  [<     inline     >] __handle_mm_fault mm/memory.c:3417
>
> Having inline functions represented in the stack trace and having file
> names with line numbers seems really useful - how did you get this
> output?  Is this a feature of some kernel patch applied for syzkaller?


I pipe normal kernel output through this script:
https://github.com/google/sanitizers/blob/master/address-sanitizer/tools/kasan_symbolize.py

If you are in linux source dir with vmlinux and modules, then you just do:
$ cat crash | kasan_symbolize.py

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web