On 06/07/2018 05:31 PM, Ross Zwisler wrote:
With a fully built QEMU I currently see the following with "git status":
Untracked files:
(use "git add ..." to include in what will be committed)
qapi/qapi-commands-job.c
qapi/qapi-commands-job.h
On 8 June 2018 at 16:59, Michael S. Tsirkin wrote:
> The expected value tests are a debugging aid. They do not catch bugs and
> aren't designed to. In particular the comparisons do not even run if
> IASL isn't installed.
If they're not actually tests to catch bugs, maybe we shouldn't
be running
This patch is reworked from an earlier patch that Dan has posted:
https://patchwork.kernel.org/patch/10131727/
VM_MIXEDMAP is used by dax to direct mm paths like vm_normal_page() that
the memory page it is dealing with is not typical memory from the linear
map. The get_user_pages_fast() path,
On Fri, Jun 8, 2018 at 10:00 AM, Dave Jiang wrote:
> This patch is reworked from an earlier patch that Dan has posted:
> https://patchwork.kernel.org/patch/10131727/
>
> VM_MIXEDMAP is used by dax to direct mm paths like vm_normal_page() that
> the memory page it is dealing with is not typical
On Fri, Jun 08, 2018 at 09:24:49AM -0500, Eric Blake wrote:
> On 06/07/2018 06:14 PM, Michael S. Tsirkin wrote:
> > On Thu, Jun 07, 2018 at 04:31:09PM -0600, Ross Zwisler wrote:
> > > This commit:
> > >
> > > commit aa78a16d8645 ("hw/i386: Rename 2.13 machine types to 3.0")
> > >
> > > updated
On Fri, Jun 08, 2018 at 05:14:09PM +0100, Peter Maydell wrote:
> On 8 June 2018 at 16:59, Michael S. Tsirkin wrote:
> > The expected value tests are a debugging aid. They do not catch bugs and
> > aren't designed to. In particular the comparisons do not even run if
> > IASL isn't installed.
>
>
On Fri, Jun 08, 2018 at 07:17:51AM +0200, Thomas Huth wrote:
> On 08.06.2018 01:09, Michael S. Tsirkin wrote:
> > On Thu, Jun 07, 2018 at 04:31:08PM -0600, Ross Zwisler wrote:
> >> Currently if "make check" detects a mismatch in the ASL generated during
> >> testing, we print an error such as:
>
On Fri, Jun 08, 2018 at 07:17:51AM +0200, Thomas Huth wrote:
> On 08.06.2018 01:09, Michael S. Tsirkin wrote:
> > On Thu, Jun 07, 2018 at 04:31:08PM -0600, Ross Zwisler wrote:
> >> Currently if "make check" detects a mismatch in the ASL generated during
> >> testing, we print an error such as:
>
The definition of BUS_MCEERR_AR is not available by default on older
glibc releases. Auto-detect this capability and de-feature the
MADV_HWPOISON injection tests if the definition is not found.
Signed-off-by: Dan Williams
---
This depends on "test: Add device-dax MADV_HWPOISON test"
On Fri, Jun 08, 2018 at 09:34:02AM -0600, Ross Zwisler wrote:
> On Fri, Jun 08, 2018 at 07:17:51AM +0200, Thomas Huth wrote:
> > On 08.06.2018 01:09, Michael S. Tsirkin wrote:
> > > On Thu, Jun 07, 2018 at 04:31:08PM -0600, Ross Zwisler wrote:
> > >> Currently if "make check" detects a mismatch in
On Fri, Jun 08, 2018 at 09:59:00AM -0500, Eric Blake wrote:
> On 06/07/2018 05:31 PM, Ross Zwisler wrote:
> > With a fully built QEMU I currently see the following with "git status":
> >
> >Untracked files:
> > (use "git add ..." to include in what will be committed)
> >
> >
On 06/07/2018 06:14 PM, Michael S. Tsirkin wrote:
On Thu, Jun 07, 2018 at 04:31:09PM -0600, Ross Zwisler wrote:
This commit:
commit aa78a16d8645 ("hw/i386: Rename 2.13 machine types to 3.0")
updated the name used to create the q35 machine, which in turn changed the
SSDT table which is
On 8 June 2018 at 17:03, Michael S. Tsirkin wrote:
> Pull requests are somewhat different, they are usually tested for lack
> of warnings. This change didn't arrive as a result of a pull request
> maybe that's why it slipped through the cracks. Peter?
>
> Maybe we need a "pedantic" flag to fail
On Fri, Jun 08, 2018 at 05:16:30PM +0100, Peter Maydell wrote:
> On 8 June 2018 at 17:03, Michael S. Tsirkin wrote:
> > Pull requests are somewhat different, they are usually tested for lack
> > of warnings. This change didn't arrive as a result of a pull request
> > maybe that's why it slipped
On Thu, Jun 07, 2018 at 04:31:11PM -0600, Ross Zwisler wrote:
> Replace the "nvdimm-cap" option which took numeric arguments such as "2"
> with a more user friendly "nvdimm-persistence" option which takes symbolic
> arguments "cpu" or "mem-ctrl".
>
> Signed-off-by: Ross Zwisler
> Suggested-by:
On 08.06.2018 20:41, Michael S. Tsirkin wrote:
> On Fri, Jun 08, 2018 at 07:23:06PM +0200, Thomas Huth wrote:
>> On 08.06.2018 18:24, Michael S. Tsirkin wrote:
>>> On Fri, Jun 08, 2018 at 05:16:30PM +0100, Peter Maydell wrote:
[...]
If there's a situation that shouldn't exist in the tree (ie
On 08.06.2018 18:24, Michael S. Tsirkin wrote:
> On Fri, Jun 08, 2018 at 05:16:30PM +0100, Peter Maydell wrote:
>> On 8 June 2018 at 17:03, Michael S. Tsirkin wrote:
>>> Pull requests are somewhat different, they are usually tested for lack
>>> of warnings. This change didn't arrive as a result
On Fri, Jun 08, 2018 at 07:23:06PM +0200, Thomas Huth wrote:
> On 08.06.2018 18:24, Michael S. Tsirkin wrote:
> > On Fri, Jun 08, 2018 at 05:16:30PM +0100, Peter Maydell wrote:
> >> On 8 June 2018 at 17:03, Michael S. Tsirkin wrote:
> >>> Pull requests are somewhat different, they are usually
On 06/08/2018 12:41 PM, Ross Zwisler wrote:
-"Set on/off to enable/disable igd passthrou", _abort);
+"Set on/off to enable/disable igd passthru", _abort);
Shouldn't that rather be "passthrough" instead?
Either works, I think. "thru" and "passthru" are short informal
In preparation for using set_memory_uc() instead set_memory_np() for
isolating poison from speculation, teach the memtype code to sanitize
physical addresses vs __PHYSICAL_MASK.
The motivation for using set_memory_uc() for this case is to allow
ongoing access to persistent memory pages via the
Define a local 'vma' variable rather than repetitively de-referencing
the passed in 'struct vm_fault *' instance.
Signed-off-by: Dan Williams
---
drivers/dax/device.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/dax/device.c
In preparation for implementing support for memory poison (media error)
handling via dax mappings, implement a lock_page() equivalent. Poison
error handling requires rmap and needs guarantees that the page->mapping
association is maintained / valid (inode not freed) for the duration of
the lookup.
In support of enabling memory_failure() handling for filesystem-dax
mappings, set ->index to the pgoff of the page. The rmap implementation
requires ->index to bound the search through the vma interval tree. The
index is set and cleared at dax_associate_entry() and
dax_disassociate_entry() time
Currently memory_failure() returns zero if the error was handled. On
that result mce_unmap_kpfn() is called to zap the page out of the kernel
linear mapping to prevent speculative fetches of potentially poisoned
memory. However, in the case of dax mapped devmap pages the page may be
in active
Changes since v3 [1]:
* Introduce dax_lock_page(), using the radix exceptional entry lock, for
pinning down page->mapping while memory_failure() interrogates the
page. (Jan)
* Collect acks and reviews from Tony and Jan.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-June/016153.html
Use new return type vm_fault_t for fault and huge_fault handler. For
now, this is just documenting that the function returns a VM_FAULT value
rather than an errno. Once all instances are converted, vm_fault_t will
become a distinct type.
Commit 1c8f422059ae ("mm: change return type to
Given that ZONE_DEVICE / dev_pagemap pages are never assembled into
compound pages, the size determination logic in kill_proc() needs
updating for the dev_pagemap case. In preparation for dev_pagemap
support rework memory_failure() and kill_proc() to pass / consume the page
size explicitly.
The madvise_inject_error() routine uses get_user_pages() to lookup the
pfn and other information for injected error, but it does not release
that pin. The assumption is that failed pages should be taken out of
circulation.
However, for dax mappings it is not possible to take pages out of
In support of enabling memory_failure() handling for device-dax
mappings, set ->index to the pgoff of the page. The rmap implementation
requires ->index to bound the search through the vma interval tree.
The ->index value is never cleared. There is no possibility for the
page to become associated
On Fri, Jun 8, 2018 at 4:58 PM Williams, Dan J wrote:
>
> Not included in this pull, but still targeting this cycle, is support
> for handling memory media errors (poison) consumed via userspace dax
> mappings.
Note that since I'm going to be traveling much of next week, I'm going
to be even
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/libnvdimm-for-4.18
...to receive the first part of the libnvdimm / persistent memory
support update for 4.18. These patches have all been in -next for
several releases. The 'DAX DMA vs Truncate' work
In support of enabling memory_failure() handling for device-dax
mappings, set the ->mapping association of pages backing device-dax
mappings. The rmap implementation requires page_mapping() to return the
address_space hosting the vmas that map the page.
The ->mapping pointer is never cleared.
mce: Uncorrected hardware memory error in user-access at af34214200
{1}[Hardware Error]: It has been corrected by h/w and requires no further
action
mce: [Hardware Error]: Machine check events logged
{1}[Hardware Error]: event severity: corrected
Memory failure: 0xaf34214:
Use clear_mce_nospec() to restore WB mode for the kernel linear mapping
of a pmem page that was marked 'HWPoison'. A page with 'HWPoison' set
has also been marked UC in PAT (page attribute table) via
set_mce_nospec() to prevent speculative retrievals of poison.
The 'HWPoison' flag is only cleared
On Fri, Jun 8, 2018 at 5:19 PM Linus Torvalds
wrote:
>
> If I get stuff that looks at all complex at the end of the merge
> window, I will just cackle unpleasantly while I press the big 'D' key
> on my keyboard.
Side note: looking at what I just pulled, there was close to a D key here too.
35 matches
Mail list logo
