are already serialized by writer lock held by dax_iomap_rw().
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 87 +++
1 file changed, 79 insertions(+), 8 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 0961625dfa05
Refactor the pmem_clear_poison() function such that the common
shared code between the typical write path and the recovery write
path is factored out.
Reviewed-by: Christoph Hellwig
Reviewed-by: Dan Williams
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 73
dax range, thus clears the
poison and puts valid data in the range.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 9 +
drivers/md/dm-linear.c| 10 ++
drivers/md/dm-log-writes.c| 10 ++
drivers/md/dm-stripe.c
DAX_ACCESS is used for normal dax access, and
DAX_RECOVERY_WRITE is used for dax recovery write.
Suggested-by: Dan Williams
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 5 +++--
drivers/md/dm-linear.c | 5 +++--
drivers/md/dm-log-writes.c | 5 +++--
drivers/md/dm
Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c
file where they belong.
While at it, fixup a function name in a comment.
Reviewed-by: Christoph Hellwig
Reviewed-by: Dan Williams
Signed-off-by: Jane Chu
---
arch/x86/include/asm/set_memory.h | 52
x pmem_do_write().
Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Reviewed-by: Christoph Hellwig
Reviewed-by: Dan Williams
Signed-off-by: Jane Chu
---
arch/x86/kernel/cpu/mce/core.c | 6 +++---
arch/x86/mm/pat/set_memory.c | 23 +++
nfit_handle_mec() hardcode poison granularity at L1_CACHE_BYTES.
Instead, let the driver rely on mce->misc register to determine
the poison granularity.
Suggested-by: Dan Williams
Reviewed-by: Dan Williams
Signed-off-by: Jane Chu
---
drivers/acpi/nfit/mce.c | 4 ++--
1 file changed
.org/all/20211106011638.2613039-1-jane@oracle.com/
Disussions about marking poisoned page as 'np'
https://lore.kernel.org/all/capcyv4hrxpb1tasbzug-ggdvs0oofkxmxlihmktg_kfi7yb...@mail.gmail.com/
Jane Chu (7):
acpi/nfit: rely on mce->misc to determine poison granularity
x86/mce
On 4/21/2022 12:35 PM, Dan Williams wrote:
> On Tue, Apr 19, 2022 at 7:05 PM Jane Chu wrote:
>>
>> Up till now, dax_direct_access() is used implicitly for normal
>> access, but for the purpose of recovery write, dax range with
>> poison is requested. To make the
On 4/20/2022 11:57 PM, Christoph Hellwig wrote:
>> +if (bb->count &&
>> +badblocks_check(bb, sector, num, &first_bad, &num_bad)) {
>
> Weird alignment here, continuing lines for conditionals are aligned
> either after the opening brace:
>
> if (bb->count &&
> badbl
On 4/20/2022 11:51 PM, Christoph Hellwig wrote:
> Looks good:
>
> Reviewed-by: Christoph Hellwig
thanks!
-jane
On 4/20/2022 11:50 PM, Christoph Hellwig wrote:
> Looks good:
>
> Reviewed-by: Christoph Hellwig
Thanks!
-jane
On 4/19/2022 11:26 PM, Dan Williams wrote:
> On Tue, Apr 19, 2022 at 7:06 PM Jane Chu wrote:
>>
>> The recovery write thread started out as a normal pwrite thread and
>> when the filesystem was told about potential media error in the
>> range, filesystem t
x pmem_do_write().
Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Signed-off-by: Jane Chu
---
arch/x86/kernel/cpu/mce/core.c | 6 +++---
arch/x86/mm/pat/set_memory.c | 23 +++
drivers/nvdimm/pmem.c | 30 +++
nfit_handle_mec() hardcode poison granularity at L1_CACHE_BYTES.
Instead, let the driver rely on mce->misc register to determine
the poison granularity.
Suggested-by: Dan Williams
Signed-off-by: Jane Chu
---
drivers/acpi/nfit/mce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
Refactor the pmem_clear_poison() function such that the common
shared code between the typical write path and the recovery write
path is factored out.
Reviewed-by: Christoph Hellwig
Reviewed-by: Dan Williams
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 73
DAX_ACCESS is used for normal dax access, and
DAX_RECOVERY_WRITE is used for dax recovery write.
Suggested-by: Dan Williams
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 5 ++--
drivers/md/dm-linear.c | 5 ++--
drivers/md/dm-log-writes.c | 5 ++--
drivers/md/dm
dax range, thus clears the
poison and puts valid data in the range.
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 9 +
drivers/md/dm-linear.c| 10 ++
drivers/md/dm-log-writes.c| 10 ++
drivers/md/dm-stripe.c| 10 ++
drivers/md
are serialized by pmem device level .recovery_lock.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 56 ++-
drivers/nvdimm/pmem.h | 1 +
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index
Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c
file where they belong.
While at it, fixup a function name in a comment.
Reviewed-by: Dan Williams
Signed-off-by: Jane Chu
---
arch/x86/include/asm/set_memory.h | 52 ---
arch/x86/mm/pat/set_memory.c
2022012626.860012-1-jane@oracle.com/T/
v3 https://lkml.org/lkml/2022/1/11/900
v2 https://lore.kernel.org/all/20211106011638.2613039-1-jane@oracle.com/
Disussions about marking poisoned page as 'np'
https://lore.kernel.org/all/capcyv4hrxpb1tasbzug-ggdvs0oofkxmxlihmktg_kfi7yb...@mail.gmail.co
On 4/13/2022 7:32 PM, Dan Williams wrote:
> On Wed, Apr 13, 2022 at 4:36 PM Jane Chu wrote:
>>
>> On 4/11/2022 4:27 PM, Dan Williams wrote:
>>> On Tue, Apr 5, 2022 at 12:48 PM Jane Chu wrote:
>>>>
>>>> The set_memory_uc() approach doesn't wo
On 4/14/2022 1:44 AM, Borislav Petkov wrote:
> On Thu, Apr 14, 2022 at 01:00:05AM +0000, Jane Chu wrote:
>> This change used to be folded in the mce patch, but for that I received
>> a review comment pointing out that the change is unrelated to the said
>> patch and doesn
On 4/12/2022 2:53 AM, Borislav Petkov wrote:
> On Tue, Apr 05, 2022 at 01:47:42PM -0600, Jane Chu wrote:
>> There is no _set_memory_prot internal helper, while coming across
>> the code, might as well fix the comment.
>>
>> Reviewed-by: Christoph Hellwig
On 4/11/2022 3:20 PM, Dan Williams wrote:
> I notice that none of the folks from "X86 MM" are on the cc, added.
>
Noted, thanks!
> On Tue, Apr 5, 2022 at 12:49 PM Jane Chu wrote:
>>
>> Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c
>> fil
On 4/11/2022 9:26 PM, Dan Williams wrote:
> On Tue, Apr 5, 2022 at 12:48 PM Jane Chu wrote:
>>
>> Refactor the pmem_clear_poison() in order to share common code
>> later.
>>
>
> I would just add a note here about why, i.e. to factor out the common
> shared cod
On 4/11/2022 10:02 PM, Christoph Hellwig wrote:
> On Mon, Apr 11, 2022 at 09:57:36PM -0700, Dan Williams wrote:
>> So how about change 'int flags' to 'enum dax_access_mode mode' where
>> dax_access_mode is:
>>
>> /**
>> * enum dax_access_mode - operational mode for dax_direct_access()
>> * @DAX
On 4/11/2022 5:08 PM, Dan Williams wrote:
> On Tue, Apr 5, 2022 at 12:48 PM Jane Chu wrote:
>>
>> Introduce DAX_RECOVERY flag to dax_direct_access(). The flag is
>> not set by default in dax_direct_access() such that the helper
>> does not translate a pmem range to ke
On 4/11/2022 4:55 PM, Dan Williams wrote:
> On Wed, Apr 6, 2022 at 10:31 PM Christoph Hellwig wrote:
>>
>> On Wed, Apr 06, 2022 at 05:32:31PM +, Jane Chu wrote:
>>> Yes, I believe Dan was motivated by avoiding the dm dance as a result of
>>> adding .recovery_w
On 4/6/2022 10:30 PM, Christoph Hellwig wrote:
> On Wed, Apr 06, 2022 at 05:32:31PM +0000, Jane Chu wrote:
>> Yes, I believe Dan was motivated by avoiding the dm dance as a result of
>> adding .recovery_write to dax_operations.
>>
>> I understand your point about .recove
On 4/12/2022 3:07 AM, Borislav Petkov wrote:
> On Tue, Apr 05, 2022 at 01:47:44PM -0600, Jane Chu wrote:
>> The set_memory_uc() approach doesn't work well in all cases.
>> For example, when "The VMM unmapped the bad page from guest
>> physical space and passed
On 4/11/2022 4:27 PM, Dan Williams wrote:
> On Tue, Apr 5, 2022 at 12:48 PM Jane Chu wrote:
>>
>> The set_memory_uc() approach doesn't work well in all cases.
>> For example, when "The VMM unmapped the bad page from guest
>> physical space and passed the machi
Resend, not sure it didn't go through.
On 4/6/2022 10:32 AM, Jane Chu wrote:
> On 4/5/2022 10:19 PM, Christoph Hellwig wrote:
>> On Tue, Apr 05, 2022 at 01:47:45PM -0600, Jane Chu wrote:
>>> Introduce DAX_RECOVERY flag to dax_direct_access(). The flag is
&g
On 4/5/2022 10:04 PM, Christoph Hellwig wrote:
> On Tue, Apr 05, 2022 at 01:47:46PM -0600, Jane Chu wrote:
>> +pmem_clear_bb(pmem, to_sect(pmem, offset), cleared >> SECTOR_SHIFT);
>> +return (cleared < len) ? BLK_STS_IOERR : BLK_STS_OK;
>
> No need fo
On 4/5/2022 10:21 PM, Christoph Hellwig wrote:
> On Tue, Apr 05, 2022 at 01:47:47PM -0600, Jane Chu wrote:
>> +off = (unsigned long)addr & ~PAGE_MASK;
>
> offset_inpage()
>
>> +if (off || !(PAGE_ALIGNED(bytes))) {
>
> No need for the inner b
On 4/5/2022 10:19 PM, Christoph Hellwig wrote:
> On Tue, Apr 05, 2022 at 01:47:45PM -0600, Jane Chu wrote:
>> Introduce DAX_RECOVERY flag to dax_direct_access(). The flag is
>> not set by default in dax_direct_access() such that the helper
>> does not translate a pmem ra
Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c
file where they belong.
Signed-off-by: Jane Chu
---
arch/x86/include/asm/set_memory.h | 52 ---
arch/x86/mm/pat/set_memory.c | 47
include/linux/set_memory.h| 9
There is no _set_memory_prot internal helper, while coming across
the code, might as well fix the comment.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jane Chu
---
arch/x86/mm/pat/set_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pat/set_memory.c b
ix
pmem_do_write().
Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Signed-off-by: Jane Chu
---
arch/x86/kernel/cpu/mce/core.c | 6 +++---
arch/x86/mm/pat/set_memory.c | 18 ++
drivers/nvdimm/pmem.c | 31 +++---
Refactor the pmem_clear_poison() in order to share common code
later.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 78 ---
1 file changed, 52 insertions(+), 26 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index
are serialized by pmem device level .recovery_lock.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 60 ++-
drivers/nvdimm/pmem.h | 1 +
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index
the uncorrectable
errors on the fly.
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 17 --
drivers/md/dm-linear.c | 4 +--
drivers/md/dm-log-writes.c | 5 +--
drivers/md/dm-stripe.c | 4 +--
drivers/md/dm-target.c | 2 +-
drivers/md/dm
sussions about marking poisoned page as 'np'
https://lore.kernel.org/all/capcyv4hrxpb1tasbzug-ggdvs0oofkxmxlihmktg_kfi7yb...@mail.gmail.com/
Jane Chu (6):
x86/mm: fix comment
x86/mce: relocate set{clear}_mce_nospec() functions
mce: fix set_mce_nospec to always unmap the whole page
On 3/22/2022 10:45 PM, Christoph Hellwig wrote:
> On Tue, Mar 22, 2022 at 11:05:09PM +0000, Jane Chu wrote:
>>> This DAX_RECOVERY doesn't actually seem to be used anywhere here or
>>> in the subsequent patches. Did I miss something?
>>
>> dax_iomap_
On 3/22/2022 10:45 PM, Christoph Hellwig wrote:
> On Tue, Mar 22, 2022 at 11:05:09PM +0000, Jane Chu wrote:
>>> This DAX_RECOVERY doesn't actually seem to be used anywhere here or
>>> in the subsequent patches. Did I miss something?
>>
>> dax_iomap_
On 3/22/2022 3:41 PM, Borislav Petkov wrote:
> On Sat, Mar 19, 2022 at 12:28:29AM -0600, Jane Chu wrote:
>> Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c
>> file where they belong.
>>
>> Signed-off-by: Jane Chu
>> ---
>>
On 3/22/2022 1:53 AM, Christoph Hellwig wrote:
>> -static void hwpoison_clear(struct pmem_device *pmem,
>> -phys_addr_t phys, unsigned int len)
>> +static phys_addr_t to_phys(struct pmem_device *pmem, phys_addr_t offset)
>> {
>> +return pmem->phys_addr + offset;
>> +}
>> +
>> +sta
On 3/22/2022 2:01 AM, Christoph Hellwig wrote:
> On Sat, Mar 19, 2022 at 12:28:31AM -0600, Jane Chu wrote:
>> Introduce DAX_RECOVERY flag to dax_direct_access(). The flag is
>> not set by default in dax_direct_access() such that the helper
>> does not translate a pmem ra
On 3/22/2022 1:44 AM, Christoph Hellwig wrote:
> On Sat, Mar 19, 2022 at 12:28:30AM -0600, Jane Chu wrote:
>> Mark poisoned page as not present, and to reverse the 'np' effect,
>> restate the _PAGE_PRESENT bit. Please refer to discussions here for
>> reaso
On 3/22/2022 1:42 AM, Christoph Hellwig wrote:
>> +EXPORT_SYMBOL(set_mce_nospec);
>
> No need for this export at all.
Indeed, my bad, will remove it.
>
>> +
>> +/* Restore full speculative operation to the pfn. */
>> +int clear_mce_nospec(unsigned long pfn)
>> +{
>> +return set_memory_wb((u
Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c
file where they belong.
Signed-off-by: Jane Chu
---
arch/x86/include/asm/set_memory.h | 52 ---
arch/x86/mm/pat/set_memory.c | 48
include/linux/set_memory.h| 9
are serialized by pmem device level .recovery_lock.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 49 ---
drivers/nvdimm/pmem.h | 1 +
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index
There is no _set_memory_prot internal helper, while coming across
the code, might as well fix the comment.
Signed-off-by: Jane Chu
---
arch/x86/mm/pat/set_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
Refactor the pmem_clear_poison() in order to share common code
later.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 81 ++-
1 file changed, 56 insertions(+), 25 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index
the uncorrectable
errors on the fly.
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 23 +--
drivers/md/dm-linear.c | 4 ++--
drivers/md/dm-log-writes.c | 5 +++--
drivers/md/dm-stripe.c | 4 ++--
drivers/md/dm-target.c | 2
marked as not-present, in order to
avoid writing to a 'np' page and trigger kernel Oops, also fix
pmem_do_write().
Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Signed-off-by: Jane Chu
---
arch/x86/kernel/cpu/mce/core.c | 6 +++---
arch/
as 'np'
https://lore.kernel.org/all/capcyv4hrxpb1tasbzug-ggdvs0oofkxmxlihmktg_kfi7yb...@mail.gmail.com/
Jane Chu (6):
x86/mm: fix comment
x86/mce: relocate set{clear}_mce_nospec() functions
mce: fix set_mce_nospec to always unmap the whole page
dax: add DAX_RECOVERY flag and .recovery_wr
On 2/3/2022 9:23 PM, Dan Williams wrote:
> On Thu, Feb 3, 2022 at 5:42 AM Christoph Hellwig wrote:
>>
>> On Wed, Feb 02, 2022 at 11:07:37PM +, Jane Chu wrote:
>>> On 2/2/2022 1:20 PM, Jane Chu wrote:
>>>>> Wouldn't it make more sense to move
On 2/3/2022 9:32 PM, Dan Williams wrote:
> On Thu, Feb 3, 2022 at 9:17 PM Dan Williams wrote:
>>
>> On Thu, Feb 3, 2022 at 5:43 AM Christoph Hellwig wrote:
>>>
>>> On Wed, Feb 02, 2022 at 09:27:42PM +, Jane Chu wrote:
>>>> Yeah, I see. Would
On 2/3/2022 9:34 PM, Dan Williams wrote:
> On Fri, Jan 28, 2022 at 1:32 PM Jane Chu wrote:
>>
>> If one of the MD raid participating target dax device supports
>> DAXDEV_RECOVERY, then it'll be declared on the whole that the
>> MD device is capable of DAXDE
On 2/3/2022 10:03 PM, Dan Williams wrote:
> On Fri, Jan 28, 2022 at 1:32 PM Jane Chu wrote:
>>
>> dax_recovery_write() dax op is only required for DAX device that
>> export DAXDEV_RECOVERY indicating its capability to recover from
>> poisons.
>>
>> DM
On 2/3/2022 10:21 PM, Dan Williams wrote:
> On Fri, Jan 28, 2022 at 1:32 PM Jane Chu wrote:
>>
>> pmem_recovery_write() consists of clearing poison via DSM,
>> clearing page HWPoison bit, re-state _PAGE_PRESENT bit,
>> cacheflush, write, and finally clearing bad-bloc
On 2/2/2022 1:20 PM, Jane Chu wrote:
> On 2/2/2022 5:21 AM, Christoph Hellwig wrote:
>>> +static inline int set_mce_nospec(unsigned long pfn)
>>>{
>>> unsigned long decoy_addr;
>>> int rc;
>>> @@ -117,10 +113,7 @@ static inline int s
On 2/2/2022 5:44 AM, Christoph Hellwig wrote:
> On Fri, Jan 28, 2022 at 02:31:49PM -0700, Jane Chu wrote:
>> +typedef size_t (*iter_func_t)(struct dax_device *dax_dev, pgoff_t pgoff,
>> +void *addr, size_t bytes, struct iov_iter *i);
>> static loff_t dax_io
On 2/2/2022 5:43 AM, Christoph Hellwig wrote:
>> @@ -257,10 +263,15 @@ static int pmem_rw_page(struct block_device *bdev,
>> sector_t sector,
>> __weak long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
>> long nr_pages, void **kaddr, pfn_t *pfn)
>> {
>> +bool
On 2/2/2022 5:34 AM, Christoph Hellwig wrote:
> On Fri, Jan 28, 2022 at 02:31:47PM -0700, Jane Chu wrote:
>> dax_recovery_write() dax op is only required for DAX device that
>> export DAXDEV_RECOVERY indicating its capability to recover from
>> poisons.
>>
>> DM m
On 2/2/2022 5:28 AM, Christoph Hellwig wrote:
> On Fri, Jan 28, 2022 at 02:31:50PM -0700, Jane Chu wrote:
>> +if (!bad_pmem) {
>> write_pmem(pmem_addr, page, page_off, len);
>> +} else {
>> +rc = pmem_clear_poison(pmem, pmem_off, l
On 2/2/2022 5:23 AM, Christoph Hellwig wrote:
> On Fri, Jan 28, 2022 at 02:31:45PM -0700, Jane Chu wrote:
>> +int dax_prep_recovery(struct dax_device *dax_dev, void **kaddr)
>> +{
>> +if (dax_recovery_capable(dax_dev)) {
>> +set_bit(DAXDEV_RECOV
On 2/2/2022 5:21 AM, Christoph Hellwig wrote:
>> +static inline int set_mce_nospec(unsigned long pfn)
>> {
>> unsigned long decoy_addr;
>> int rc;
>> @@ -117,10 +113,7 @@ static inline int set_mce_nospec(unsigned long pfn,
>> bool unmap)
>> */
>> decoy_addr = (pfn << PAGE_SH
dax_recovery_write() dax op is only required for DAX device that
export DAXDEV_RECOVERY indicating its capability to recover from
poisons.
DM may be nested, if part of the base dax devices forming a DM
device support dax recovery, the DM device is marked with such
capability.
Signed-off-by: Jane
Since poisoned page is marked as not-present, the first of the
two back-to-back write_pmem() calls can only be made when there
is no poison in the range, otherwise kernel Oops.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions
dax_iomap_iter() fails if the destination range contains poison.
Add recovery_write to the failure code path.
Signed-off-by: Jane Chu
---
fs/dax.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index cd03485867a7..236675bd5946
thread is serialized by a lock.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 82 +++
drivers/nvdimm/pmem.h | 1 +
2 files changed, 77 insertions(+), 6 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 638e64681db9
maybe recovered, or not.
Signed-off-by: Jane Chu
---
drivers/md/dm-table.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index e43096cfe9e2..8af8a81b6172 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-ta
/20211106011638.2613039-1-jane@oracle.com/
Disussions about marking poisoned page as 'np':
https://lore.kernel.org/all/capcyv4hrxpb1tasbzug-ggdvs0oofkxmxlihmktg_kfi7yb...@mail.gmail.com/
Jane Chu (7):
mce: fix set_mce_nospec to always unmap the whole page
dax: introduce dax d
1ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Signed-off-by: Jane Chu
---
arch/x86/include/asm/set_memory.h | 17 +
arch/x86/kernel/cpu/mce/core.c| 6 +++---
arch/x86/mm/pat/set_memory.c | 8 +++-
include/linux/set_memory.h| 2 +-
4 files ch
.
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 24
drivers/nvdimm/pmem.c | 1 +
include/linux/dax.h | 14 ++
3 files changed, 39 insertions(+)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index e3029389d809..f4f607d9698b 100644
--- a/drivers
On 1/24/2022 1:01 AM, Christoph Hellwig wrote:
> On Fri, Jan 21, 2022 at 01:33:40AM +0000, Jane Chu wrote:
>>> What tree is this against? I can't apply it to either 5.16 or Linus'
>>> current tree.
>>
>> It was based on your 'dax-block-cleanup'
Since poisoned page is marked as not-present, the first of the
two back-to-back write_pmem() calls can only be made when there
is no poison in the range, otherwise kernel Oops.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions
dax_iomap_iter() fails if the destination range contains poison.
Add recovery_write to the failure code path.
Signed-off-by: Jane Chu
---
fs/dax.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index cd03485867a7..236675bd5946
dax_recovery_write() dax op is only required for DAX device that
export DAXDEV_RECOVERY indicating its capability to recover from
poisons.
DM may be nested, if part of the base dax devices forming a DM
device support dax recovery, the DM device is marked with such
capability.
Signed-off-by: Jane
thread is serialized by a lock.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 82 +++
drivers/nvdimm/pmem.h | 1 +
2 files changed, 77 insertions(+), 6 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 638e64681db9
.
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 24
drivers/nvdimm/pmem.c | 1 +
include/linux/dax.h | 15 +++
3 files changed, 40 insertions(+)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index e3029389d809..f4f607d9698b 100644
--- a/drivers
1ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Signed-off-by: Jane Chu
---
arch/x86/include/asm/set_memory.h | 17 +
arch/x86/kernel/cpu/mce/core.c| 6 +++---
arch/x86/mm/pat/set_memory.c | 8 +++-
include/linux/set_memory.h| 2 +-
4 files ch
maybe recovered, or not.
Signed-off-by: Jane Chu
---
drivers/md/dm-table.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index e43096cfe9e2..8af8a81b6172 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-ta
pb1tasbzug-ggdvs0oofkxmxlihmktg_kfi7yb...@mail.gmail.com/
Jane Chu (7):
mce: fix set_mce_nospec to always unmap the whole page
dax: introduce dax device flag DAXDEV_RECOVERY
dm: make dm aware of target's DAXDEV_RECOVERY capability
dax: add dax_recovery_write to dax_op and dm target t
On 1/20/2022 1:55 AM, Christoph Hellwig wrote:
> On Tue, Jan 11, 2022 at 11:59:23AM -0700, Jane Chu wrote:
>> In v3, dax recovery code path is independent of that of
>> normal write. Competing dax recovery threads are serialized,
>> racing read threads are guaranteed not
Since poisoned page is marked as not-present, the first of the
two back-to-back write_pmem() calls can only be made when there
is no poison in the range, otherwise kernel Oops.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions
dax_iomap_iter() fails if the destination range contains poison.
Add recovery_write to the failure code path.
Signed-off-by: Jane Chu
---
fs/dax.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index e0eecd8e3a8f..c16362d3993c
granularity.
Please refer to below discussions for more information:
v2:
https://lore.kernel.org/all/20211106011638.2613039-1-jane@oracle.com/
Disussions about marking poisoned page as 'np':
https://lore.kernel.org/all/capcyv4hrxpb1tasbzug-ggdvs0oofkxmxlihmktg_kfi7yb...@mail.gmail.com/
J
thread is serialized by a lock.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 84 +++
drivers/nvdimm/pmem.h | 1 +
2 files changed, 79 insertions(+), 6 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index a68e7d3ed27e
dax_recovery_write() dax op is only required for DAX device that
export DAXDEV_RECOVERY indicating its capability to recover from
poisons.
DM may be nested, if part of the base dax devices forming a DM
device support dax recovery, the DM device is marked with such
capability.
Signed-off-by: Jane
1ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Signed-off-by: Jane Chu
---
arch/x86/include/asm/set_memory.h | 17 +
arch/x86/kernel/cpu/mce/core.c| 6 +++---
arch/x86/mm/pat/set_memory.c | 8 +++-
include/linux/set_memory.h| 2 +-
4 files ch
maybe recovered, or not.
Signed-off-by: Jane Chu
---
drivers/md/dm-table.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index e43096cfe9e2..8af8a81b6172 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-ta
.
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 34 ++
drivers/nvdimm/pmem.c | 1 +
include/linux/dax.h | 3 +++
3 files changed, 38 insertions(+)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index e7152a6c4cc4..bfb2f5d0921e 100644
--- a/drivers
On 11/12/2021 7:36 AM, Mike Snitzer wrote:
> On Wed, Nov 10 2021 at 1:26P -0500,
> Jane Chu wrote:
>
>> On 11/9/2021 1:02 PM, Dan Williams wrote:
>>> On Tue, Nov 9, 2021 at 11:59 AM Jane Chu wrote:
>>>>
>>>> On 11/9/2021 10:48 AM, Dan Willi
On 11/9/2021 1:02 PM, Dan Williams wrote:
> On Tue, Nov 9, 2021 at 11:59 AM Jane Chu wrote:
>>
>> On 11/9/2021 10:48 AM, Dan Williams wrote:
>>> On Mon, Nov 8, 2021 at 11:27 PM Christoph Hellwig
>>> wrote:
>>>>
>>>> On Fri, Nov 05,
On 11/9/2021 10:48 AM, Dan Williams wrote:
> On Mon, Nov 8, 2021 at 11:27 PM Christoph Hellwig wrote:
>>
>> On Fri, Nov 05, 2021 at 07:16:38PM -0600, Jane Chu wrote:
>>> static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t
>>> pgoff,
>>&g
On 11/8/2021 11:27 PM, Christoph Hellwig wrote:
> On Fri, Nov 05, 2021 at 07:16:38PM -0600, Jane Chu wrote:
>> static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t
>> pgoff,
>> void *addr, size_t bytes, struct iov_iter *i, int mode)
>&
On 11/6/2021 9:48 AM, Dan Williams wrote:
> On Fri, Nov 5, 2021 at 6:17 PM Jane Chu wrote:
>>
>> Introduce DAX_OP_NORMAL and DAX_OP_RECOVERY operation modes to
>> {dax_direct_access, dax_copy_from_iter, dax_copy_to_iter}.
>> DAX_OP_NORMAL is the defaul
1 - 100 of 139 matches
Mail list logo