All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 201631] WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page_dirty+0x70/0xb0
Date: Thu, 24 Jan 2019 03:40:18 +0000	[thread overview]
Message-ID: <bug-201631-13602-7YZqhMcXfx@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-201631-13602@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=201631

--- Comment #50 from Aneesh Kumar KV (aneesh.kumar@linux.ibm.com) ---
(In reply to Jan Kara from comment #47)
> OK, so it seems to be more and more clear that PPC indeed has some race in
> page table updates. What I can see in the latest report is:
> 
> Clean page (index 92, ino 681741, i_size 828368, flags 7fff0000002016,
> mapcount 1) with dirty PTE (pte_val c0000005f7fae186) on unmap! Vma flags
> fb, pgoff 0, file ino 681741
> ...
> page 92: b_state 21, b_blocknr 2801084, b_mapped 1452389112002, b_mapped2 0,
> b_cleaned 1452396217779, now 1452400395514
> 
> So "Vma flags fb" shows its a normal shared, writeable file mapping. Page is
> somewhere in the middle of the file (file size is 828368, page is at offset
> 376832). The page has been writeably mapped 11ms ago (you are using ext2
> filesystem which was confusing my previous debug attempts so only this one
> has shown proper times) and written back 4ms ago (which should have
> writeprotected the pte) but we still have writeable pte now on which the
> assertion hits. So either page_mkclean() failed to clear the PTE or someone
> created new writeable PTE without telling ext4.
> 
> I'll attach a new version of debug patch to distinguish these two cases.

The fact that we did try to write out the page at (bh_cleaned
1452396217779)implies we should have cleared the _PAGE_WRITE bit right
(clear_page_dirty_for_io())? So we should either find that bit cleared in pte
(if we missed a related tlb flush and tlb still has that pte with _PAGE_WRITE)
or we find that set. In this case, we find _PAGE_WRITE set in the pte during
zap. Does that imply we did call finish_fault()? which should have ideally
resulted in we calling page_mkwrite().

I am still not clear what could be a possible race that can result in this?

-aneesh

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2019-01-24  3:41 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-07 18:14 [Bug 201631] New: WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page_dirty+0x70/0xb0 bugzilla-daemon
2018-11-07 18:14 ` [Bug 201631] " bugzilla-daemon
2018-11-07 22:09 ` bugzilla-daemon
2018-11-08 11:44 ` bugzilla-daemon
2018-11-28 10:41 ` bugzilla-daemon
2018-11-28 11:00 ` bugzilla-daemon
2018-11-28 17:14 ` bugzilla-daemon
2018-11-28 17:19 ` bugzilla-daemon
2018-12-11 11:21 ` bugzilla-daemon
2018-12-16 13:26 ` bugzilla-daemon
2018-12-16 13:27 ` bugzilla-daemon
2018-12-16 20:47 ` bugzilla-daemon
2018-12-17 10:58 ` bugzilla-daemon
2018-12-17 11:30 ` bugzilla-daemon
2018-12-17 11:51 ` bugzilla-daemon
2018-12-17 12:15 ` bugzilla-daemon
2018-12-17 16:51 ` bugzilla-daemon
2018-12-17 16:52 ` bugzilla-daemon
2018-12-17 17:50 ` bugzilla-daemon
2018-12-18  8:45 ` bugzilla-daemon
2018-12-18 22:27 ` bugzilla-daemon
2018-12-19 13:39 ` bugzilla-daemon
2018-12-19 17:03 ` bugzilla-daemon
2018-12-19 22:58 ` bugzilla-daemon
2018-12-19 23:03 ` bugzilla-daemon
2018-12-20  4:15 ` bugzilla-daemon
2018-12-20  4:21 ` bugzilla-daemon
2018-12-20  7:41 ` bugzilla-daemon
2018-12-20  7:49 ` bugzilla-daemon
2018-12-20  8:21 ` bugzilla-daemon
2018-12-20  8:35 ` bugzilla-daemon
2018-12-20  9:10 ` bugzilla-daemon
2018-12-20  9:29 ` bugzilla-daemon
2018-12-21  0:26 ` bugzilla-daemon
2018-12-21 11:16 ` bugzilla-daemon
2018-12-21 11:17 ` bugzilla-daemon
2018-12-21 11:52 ` bugzilla-daemon
2018-12-21 23:47 ` bugzilla-daemon
2018-12-22 14:13 ` bugzilla-daemon
2019-01-02 15:10 ` bugzilla-daemon
2019-01-02 15:46 ` bugzilla-daemon
2019-01-08 23:00 ` bugzilla-daemon
2019-01-08 23:02 ` bugzilla-daemon
2019-01-17 10:32 ` bugzilla-daemon
2019-01-17 11:48 ` bugzilla-daemon
2019-01-22 23:09 ` bugzilla-daemon
2019-01-22 23:10 ` bugzilla-daemon
2019-01-23 16:40 ` bugzilla-daemon
2019-01-23 16:41 ` bugzilla-daemon
2019-01-23 16:42 ` bugzilla-daemon
2019-01-24  3:17 ` bugzilla-daemon
2019-01-24  3:40 ` bugzilla-daemon [this message]
2019-01-24  8:15 ` bugzilla-daemon
2019-01-26 16:03 ` bugzilla-daemon
2019-01-27 14:48 ` bugzilla-daemon
2019-01-29  9:40 ` bugzilla-daemon
2019-01-29  9:41 ` bugzilla-daemon
2019-01-29 12:13 ` bugzilla-daemon
2019-01-29 14:48 ` bugzilla-daemon
2019-01-30 12:53 ` bugzilla-daemon
2019-01-30 12:59 ` bugzilla-daemon
2019-01-31  0:31 ` bugzilla-daemon
2019-01-31  0:32 ` bugzilla-daemon
2019-01-31  9:10 ` bugzilla-daemon
2019-02-04  6:37 ` bugzilla-daemon
2019-02-04  6:38 ` bugzilla-daemon
2019-02-04  6:39 ` bugzilla-daemon
2019-02-04 22:30 ` bugzilla-daemon
2019-02-04 22:33 ` bugzilla-daemon
2019-02-05  8:42 ` bugzilla-daemon
2019-02-05  9:21 ` bugzilla-daemon
2019-02-05 11:43 ` bugzilla-daemon
2019-02-05 12:21 ` bugzilla-daemon
2019-02-07  9:06 ` bugzilla-daemon
2019-02-07 11:29 ` bugzilla-daemon
2019-02-07 13:03 ` bugzilla-daemon
2019-02-07 13:05 ` bugzilla-daemon

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=bug-201631-13602-7YZqhMcXfx@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@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.