From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM64: kernel panics in DABT in sys_msync path
Date: Tue, 26 Sep 2017 11:23:24 +0100 [thread overview]
Message-ID: <20170926102324.GC8693@arm.com> (raw)
In-Reply-To: <a3b714ae-97a5-8458-9bf7-140eeeebc4b9@codeaurora.org>
On Mon, Sep 25, 2017 at 01:54:57PM -0600, Ruigrok, Richard wrote:
> I also found this issue with kernels from 4.11 through 4.13. In my tests, I
> found that it reproduces only with 4K page and Transparent Huge Pages. With 64K
> page I was not able to reproduce. RH also reported it here: https://
> bugzilla.redhat.com/show_bug.cgi?id=1491504 Linaro reported on the RPK kernel
> (4.12) on Centriq2400 and ThunderX
>
>
> https://bugs.linaro.org/show_bug.cgi?id=3191
>
> https://bugs.linaro.org/show_bug.cgi?id=3068.
These two aren't the same bug (that's a forward progress issue that we're
currently working on). I don't have permission to look at the redhat one,
but is it just an RCU stall or actually the Oops reported by Yury?
> I was able to bisect down to a specific commit.
I think we're chasing two different things here, so not sure I trust the
bisect!
Will
> First bad commit is:
> commit f27176cfc363d395eea8dc5c4a26e5d6d7d65eaf
> Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Date: Fri Feb 24 14:57:57 2017 -0800
>
> mm: convert page_mkclean_one() to use page_vma_mapped_walk()
>
> For consistency, it worth converting all page_check_address() to
> page_vma_mapped_walk(), so we could drop the former.
>
> PMD handling here is future-proofing, we don't have users yet. ext4
> with huge pages will be the first.
>
> I did not use virtualization, simply booting kernel and running the LTP
> rwtest: ./runltp -p -f fs -s rwtest
> To validate bisecting (good points), I ran 30 iterations. Usually it
> reproduces in 5-10 iterations.
>
> If you have any suggestions for instrumentation I can run tests, we can work
> with 4.13 or on 4.11 at the above bisect point.
> I have not tried the 4.14-rc's yet.
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: "Ruigrok, Richard" <rruigrok@codeaurora.org>
Cc: Yury Norov <ynorov@caviumnetworks.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: ARM64: kernel panics in DABT in sys_msync path
Date: Tue, 26 Sep 2017 11:23:24 +0100 [thread overview]
Message-ID: <20170926102324.GC8693@arm.com> (raw)
In-Reply-To: <a3b714ae-97a5-8458-9bf7-140eeeebc4b9@codeaurora.org>
On Mon, Sep 25, 2017 at 01:54:57PM -0600, Ruigrok, Richard wrote:
> I also found this issue with kernels from 4.11 through 4.13. In my tests, I
> found that it reproduces only with 4K page and Transparent Huge Pages. With 64K
> page I was not able to reproduce. RH also reported it here: https://
> bugzilla.redhat.com/show_bug.cgi?id=1491504 Linaro reported on the RPK kernel
> (4.12) on Centriq2400 and ThunderX
>
>
> https://bugs.linaro.org/show_bug.cgi?id=3191
>
> https://bugs.linaro.org/show_bug.cgi?id=3068.
These two aren't the same bug (that's a forward progress issue that we're
currently working on). I don't have permission to look at the redhat one,
but is it just an RCU stall or actually the Oops reported by Yury?
> I was able to bisect down to a specific commit.
I think we're chasing two different things here, so not sure I trust the
bisect!
Will
> First bad commit is:
> commit f27176cfc363d395eea8dc5c4a26e5d6d7d65eaf
> Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Date: Fri Feb 24 14:57:57 2017 -0800
>
> mm: convert page_mkclean_one() to use page_vma_mapped_walk()
>
> For consistency, it worth converting all page_check_address() to
> page_vma_mapped_walk(), so we could drop the former.
>
> PMD handling here is future-proofing, we don't have users yet. ext4
> with huge pages will be the first.
>
> I did not use virtualization, simply booting kernel and running the LTP
> rwtest: ./runltp -p -f fs -s rwtest
> To validate bisecting (good points), I ran 30 iterations. Usually it
> reproduces in 5-10 iterations.
>
> If you have any suggestions for instrumentation I can run tests, we can work
> with 4.13 or on 4.11 at the above bisect point.
> I have not tried the 4.14-rc's yet.
next prev parent reply other threads:[~2017-09-26 10:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-24 21:36 ARM64: kernel panics in DABT in sys_msync path Yury Norov
2017-09-24 21:36 ` Yury Norov
2017-09-25 10:53 ` Will Deacon
2017-09-25 10:53 ` Will Deacon
2017-09-25 14:02 ` Yury Norov
2017-09-25 14:02 ` Yury Norov
2017-09-25 19:04 ` Yury Norov
2017-09-25 19:04 ` Yury Norov
2017-09-25 20:52 ` Ruigrok, Richard
2017-09-25 20:52 ` Ruigrok, Richard
[not found] ` <a3b714ae-97a5-8458-9bf7-140eeeebc4b9@codeaurora.org>
2017-09-26 10:23 ` Will Deacon [this message]
2017-09-26 10:23 ` Will Deacon
2017-09-26 11:54 ` Yury Norov
2017-09-26 11:54 ` Yury Norov
2017-09-26 14:23 ` Ruigrok, Richard
2017-09-26 14:23 ` Ruigrok, Richard
2017-09-26 17:31 ` Will Deacon
2017-09-26 17:31 ` Will Deacon
2017-09-27 15:50 ` Will Deacon
2017-09-27 15:50 ` Will Deacon
2017-09-27 18:00 ` Richard Ruigrok
2017-09-27 18:00 ` Richard Ruigrok
2017-09-28 3:31 ` Richard Ruigrok
2017-09-28 3:31 ` Richard Ruigrok
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=20170926102324.GC8693@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.