All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <yuchao0@huawei.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-fsdevel@vger.kernel.org>,
	<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: fix stale ATOMIC_WRITTEN_PAGE private pointer
Date: Fri, 17 Mar 2017 14:51:02 +0800	[thread overview]
Message-ID: <bee4a60b-552a-2afd-0db5-2825e48b742b@huawei.com> (raw)
In-Reply-To: <20170317020906.28165-1-jaegeuk@kernel.org>

On 2017/3/17 10:09, Jaegeuk Kim wrote:
> When I forced to enable atomic operations intentionally, I could hit the below
> panic, since we didn't clear page->private in f2fs_invalidate_page called by
> file truncation.
> 
> The panic occurs due to NULL mapping having page->private.
> 
> BUG: unable to handle kernel paging request at ffffffffffffffff
> IP: drop_buffers+0x38/0xe0
> PGD 5d00c067
> PUD 5d00e067
> PMD 0
> CPU: 3 PID: 1648 Comm: fsstress Tainted: G      D    OE   4.10.0+ #5
> Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> task: ffff9151952863c0 task.stack: ffffaaec40db4000
> RIP: 0010:drop_buffers+0x38/0xe0
> RSP: 0018:ffffaaec40db74c8 EFLAGS: 00010292
> Call Trace:
>  ? page_referenced+0x8b/0x170
>  try_to_free_buffers+0xc5/0xe0
>  try_to_release_page+0x49/0x50
>  shrink_page_list+0x8bc/0x9f0
>  shrink_inactive_list+0x1dd/0x500
>  ? shrink_active_list+0x2c0/0x430
>  shrink_node_memcg+0x5eb/0x7c0
>  shrink_node+0xe1/0x320
>  do_try_to_free_pages+0xef/0x2e0
>  try_to_free_pages+0xe9/0x190
>  __alloc_pages_slowpath+0x390/0xe70
>  __alloc_pages_nodemask+0x291/0x2b0
>  alloc_pages_current+0x95/0x140
>  __page_cache_alloc+0xc4/0xe0
>  pagecache_get_page+0xab/0x2a0
>  grab_cache_page_write_begin+0x20/0x40
>  get_read_data_page+0x2e6/0x4c0 [f2fs]
>  ? f2fs_mark_inode_dirty_sync+0x16/0x30 [f2fs]
>  ? truncate_data_blocks_range+0x238/0x2b0 [f2fs]
>  get_lock_data_page+0x30/0x190 [f2fs]
>  __exchange_data_block+0xaaf/0xf40 [f2fs]
>  f2fs_fallocate+0x418/0xd00 [f2fs]
>  vfs_fallocate+0x157/0x220
>  SyS_fallocate+0x48/0x80
> 
> Signed-off-by: Yunlei He <heyunlei@huawei.com>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>

Reviewed-by: Chao Yu <yuchao0@huawei.com>

WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu <yuchao0@huawei.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: fix stale ATOMIC_WRITTEN_PAGE private pointer
Date: Fri, 17 Mar 2017 14:51:02 +0800	[thread overview]
Message-ID: <bee4a60b-552a-2afd-0db5-2825e48b742b@huawei.com> (raw)
In-Reply-To: <20170317020906.28165-1-jaegeuk@kernel.org>

On 2017/3/17 10:09, Jaegeuk Kim wrote:
> When I forced to enable atomic operations intentionally, I could hit the below
> panic, since we didn't clear page->private in f2fs_invalidate_page called by
> file truncation.
> 
> The panic occurs due to NULL mapping having page->private.
> 
> BUG: unable to handle kernel paging request at ffffffffffffffff
> IP: drop_buffers+0x38/0xe0
> PGD 5d00c067
> PUD 5d00e067
> PMD 0
> CPU: 3 PID: 1648 Comm: fsstress Tainted: G      D    OE   4.10.0+ #5
> Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> task: ffff9151952863c0 task.stack: ffffaaec40db4000
> RIP: 0010:drop_buffers+0x38/0xe0
> RSP: 0018:ffffaaec40db74c8 EFLAGS: 00010292
> Call Trace:
>  ? page_referenced+0x8b/0x170
>  try_to_free_buffers+0xc5/0xe0
>  try_to_release_page+0x49/0x50
>  shrink_page_list+0x8bc/0x9f0
>  shrink_inactive_list+0x1dd/0x500
>  ? shrink_active_list+0x2c0/0x430
>  shrink_node_memcg+0x5eb/0x7c0
>  shrink_node+0xe1/0x320
>  do_try_to_free_pages+0xef/0x2e0
>  try_to_free_pages+0xe9/0x190
>  __alloc_pages_slowpath+0x390/0xe70
>  __alloc_pages_nodemask+0x291/0x2b0
>  alloc_pages_current+0x95/0x140
>  __page_cache_alloc+0xc4/0xe0
>  pagecache_get_page+0xab/0x2a0
>  grab_cache_page_write_begin+0x20/0x40
>  get_read_data_page+0x2e6/0x4c0 [f2fs]
>  ? f2fs_mark_inode_dirty_sync+0x16/0x30 [f2fs]
>  ? truncate_data_blocks_range+0x238/0x2b0 [f2fs]
>  get_lock_data_page+0x30/0x190 [f2fs]
>  __exchange_data_block+0xaaf/0xf40 [f2fs]
>  f2fs_fallocate+0x418/0xd00 [f2fs]
>  vfs_fallocate+0x157/0x220
>  SyS_fallocate+0x48/0x80
> 
> Signed-off-by: Yunlei He <heyunlei@huawei.com>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>

Reviewed-by: Chao Yu <yuchao0@huawei.com>

  parent reply	other threads:[~2017-03-17  6:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17  2:09 [PATCH 1/2] f2fs: fix stale ATOMIC_WRITTEN_PAGE private pointer Jaegeuk Kim
2017-03-17  2:09 ` Jaegeuk Kim
2017-03-17  2:09 ` [PATCH 2/2] f2fs: don't allow atomic writes for not regular files Jaegeuk Kim
2017-03-17  2:09   ` Jaegeuk Kim
2017-03-17  3:23   ` [f2fs-dev] " Chao Yu
2017-03-17  3:23     ` Chao Yu
2017-03-17 12:40     ` [f2fs-dev] " Jaegeuk Kim
2017-03-17 12:40       ` Jaegeuk Kim
2017-03-17  6:51 ` Chao Yu [this message]
2017-03-17  6:51   ` [f2fs-dev] [PATCH 1/2] f2fs: fix stale ATOMIC_WRITTEN_PAGE private pointer Chao Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bee4a60b-552a-2afd-0db5-2825e48b742b@huawei.com \
    --to=yuchao0@huawei.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.