Re: [PATCH] arm64: add pmem module for kernel update
Hi Zhuling, On Wed, Dec 30, 2020 at 10:18 PM Zhuling wrote: > > Category: feature > Bugzilla: NA > CVE: NA These tags can be dropped. > > Use reserved memory to create a pmem device to store the > processes information that dumped before kernel update. > When you want to use this feature you need to declare by > "pmemmem=pmem_size:pmem_phystart" in cmdline. > (exp: pmemmem=100M:0x2020) > Interesting. I like the feature, but it's not clear to me that a new command line based configuration scheme is needed. There is the existing memmap= parameter that on x86 describes a IORES_DESC_PERSISTENT_MEMORY_LEGACY range. The driver/nvdimm/e820.c driver could be reworked to attach to the same thing on ARM64. Then as far as assigning memory to different kernel usages there is the existing capability in libnvdimm to attach a "personality" to an nvdimm namespace. I imagine you could write a special signature to the namespace that libnvdimm would recognize as a KUP reservation namespace and work generically across any arch. ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v3] arch/arc: add copy_user_page() to to fix build error on ARC
On 1/4/21 7:44 PM, Randy Dunlap wrote: > fs/dax.c uses copy_user_page() but ARC does not provide that interface, > resulting in a build error. > > Provide copy_user_page() in . > > ../fs/dax.c: In function 'copy_cow_page_dax': > ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; > did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] > > Reported-by: kernel test robot > Signed-off-by: Randy Dunlap > Cc: Vineet Gupta > Cc: linux-snps-...@lists.infradead.org > Cc: Dan Williams > #Acked-by: Vineet Gupta # v1 > Cc: Andrew Morton > Cc: Matthew Wilcox > Cc: Jan Kara > Cc: linux-fsde...@vger.kernel.org > Cc: linux-nvdimm@lists.01.org > #Reviewed-by: Ira Weiny # v2 Added to arc #for-curr. Thx, -Vineet > --- > v2: rebase, add more Cc: > v3: add copy_user_page() to arch/arc/include/asm/page.h > > arch/arc/include/asm/page.h |1 + > > --- lnx-511-rc1.orig/arch/arc/include/asm/page.h > +++ lnx-511-rc1/arch/arc/include/asm/page.h > @@ -10,6 +10,7 @@ > #ifndef __ASSEMBLY__ > > #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) > +#define copy_user_page(to, from, vaddr, pg) copy_page(to, from) > #define copy_page(to, from) memcpy((to), (from), PAGE_SIZE) > > struct vm_area_struct; > ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] x86/mm: Fix leak of pmd ptlock
Ping, this bug is still present on v5.11-rc2, need a resend?
On Wed, Dec 2, 2020 at 10:28 PM Dan Williams wrote:
>
> Commit 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
> introduced a new location where a pmd was released, but neglected to run
> the pmd page destructor. In fact, this happened previously for a
> different pmd release path and was fixed by commit:
>
> c283610e44ec ("x86, mm: do not leak page->ptl for pmd page tables").
>
> This issue was hidden until recently because the failure mode is silent,
> but commit:
>
> b2b29d6d0119 ("mm: account PMD tables like PTE tables")
>
> ...turns the failure mode into this signature:
>
> BUG: Bad page state in process lt-pmem-ns pfn:15943d
> page:7262ed7b refcount:0 mapcount:-1024 mapping:
> index:0x0 pfn:0x15943d
> flags: 0xa8()
> raw: 00a8 dead0100
> raw: 913a029bcc08 fbff
> page dumped because: nonzero mapcount
> [..]
> dump_stack+0x8b/0xb0
> bad_page.cold+0x63/0x94
> free_pcp_prepare+0x224/0x270
> free_unref_page+0x18/0xd0
> pud_free_pmd_page+0x146/0x160
> ioremap_pud_range+0xe3/0x350
> ioremap_page_range+0x108/0x160
> __ioremap_caller.constprop.0+0x174/0x2b0
> ? memremap+0x7a/0x110
> memremap+0x7a/0x110
> devm_memremap+0x53/0xa0
> pmem_attach_disk+0x4ed/0x530 [nd_pmem]
> ? __devm_release_region+0x52/0x80
> nvdimm_bus_probe+0x85/0x210 [libnvdimm]
>
> Given this is a repeat occurrence it seemed prudent to look for other
> places where this destructor might be missing and whether a better
> helper is needed. try_to_free_pmd_page() looks like a candidate, but
> testing with setting up and tearing down pmd mappings via the dax unit
> tests is thus far not triggering the failure. As for a better helper
> pmd_free() is close, but it is a messy fit due to requiring an @mm arg.
> Also, ___pmd_free_tlb() wants to call paravirt_tlb_remove_table()
> instead of free_page(), so open-coded pgtable_pmd_page_dtor() seems the
> best way forward for now.
>
> Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
> Cc:
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
> Cc: "H. Peter Anvin"
> Co-debugged-by: Matthew Wilcox
> Tested-by: Yi Zhang
> Signed-off-by: Dan Williams
> ---
> arch/x86/mm/pgtable.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> index dfd82f51ba66..f6a9e2e36642 100644
> --- a/arch/x86/mm/pgtable.c
> +++ b/arch/x86/mm/pgtable.c
> @@ -829,6 +829,8 @@ int pud_free_pmd_page(pud_t *pud, unsigned long addr)
> }
>
> free_page((unsigned long)pmd_sv);
> +
> + pgtable_pmd_page_dtor(virt_to_page(pmd));
> free_page((unsigned long)pmd);
>
> return 1;
>
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2] fs/dax: include to fix build error on ARC
On Thu, Dec 31, 2020 at 08:29:14PM -0800, Randy Dunlap wrote: > fs/dax.c uses copy_user_page() but ARC does not provide that interface, > resulting in a build error. > > Provide copy_user_page() in (beside copy_page()) and > add to fs/dax.c to fix the build error. > > ../fs/dax.c: In function 'copy_cow_page_dax': > ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; > did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Could somebody explain what the force-cast is doing in there? I mean, the call is copy_user_page(vto, (void __force *)kaddr, vaddr, to); kaddr is a local variable there, declared as void *; AFAICS, that had been pure cargo-cult since commit 7a9eb20666317794d0279843fbd091af93907780 Author: Dan Williams Date: Fri Jun 3 18:06:47 2016 -0700 pmem: kill __pmem address space I mean, it's been more than 4 years, time to bury that body... ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2] fs/dax: include to fix build error on ARC
On Mon, Jan 4, 2021 at 7:47 PM Randy Dunlap wrote:
>
> On 1/4/21 12:13 PM, Dan Williams wrote:
> > On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
> >>
> >> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> >> resulting in a build error.
> >>
> >> Provide copy_user_page() in (beside copy_page()) and
> >> add to fs/dax.c to fix the build error.
> >>
> >> ../fs/dax.c: In function 'copy_cow_page_dax':
> >> ../fs/dax.c:702:2: error: implicit declaration of function
> >> 'copy_user_page'; did you mean 'copy_to_user_page'?
> >> [-Werror=implicit-function-declaration]
> >>
> >> Fixes: cccbce671582 ("filesystem-dax: convert to dax_direct_access()")
> >> Reported-by: kernel test robot
> >> Signed-off-by: Randy Dunlap
> >> Cc: Vineet Gupta
> >> Cc: linux-snps-...@lists.infradead.org
> >> Cc: Dan Williams
> >> Acked-by: Vineet Gupta
> >> Cc: Andrew Morton
> >> Cc: Matthew Wilcox
> >> Cc: Jan Kara
> >> Cc: linux-fsde...@vger.kernel.org
> >> Cc: linux-nvdimm@lists.01.org
> >> ---
> >> v2: rebase, add more Cc:
> >>
> >> arch/arc/include/asm/page.h |1 +
> >> fs/dax.c|1 +
> >> 2 files changed, 2 insertions(+)
> >>
> >> --- lnx-511-rc1.orig/fs/dax.c
> >> +++ lnx-511-rc1/fs/dax.c
> >> @@ -25,6 +25,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >
> > I would expect this to come from one of the linux/ includes like
> > linux/mm.h. asm/ headers are implementation linux/ headers are api.
> >
> > Once you drop that then the subject of this patch can just be "arc:
> > add a copy_user_page() implementation", and handled by the arc
> > maintainer (or I can take it with Vineet's ack).
>
> Got it. Thanks.
> Vineet is copied. I expect that he will take the v3 patch.
>
> >> #include
> >
> > Yes, this one should have a linux/ api header to front it, but that's
> > a cleanup for another day.
>
> That line is only part of the contextual diff in this patch.
> I guess you are just commenting in general, along with your earlier
> paragraph.
Yes, I was prefetching a "...hey, but, there's an asm/ include right
below this one?"
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
[PATCH v3] arch/arc: add copy_user_page() to to fix build error on ARC
fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-...@lists.infradead.org Cc: Dan Williams #Acked-by: Vineet Gupta # v1 Cc: Andrew Morton Cc: Matthew Wilcox Cc: Jan Kara Cc: linux-fsde...@vger.kernel.org Cc: linux-nvdimm@lists.01.org #Reviewed-by: Ira Weiny # v2 --- v2: rebase, add more Cc: v3: add copy_user_page() to arch/arc/include/asm/page.h arch/arc/include/asm/page.h |1 + --- lnx-511-rc1.orig/arch/arc/include/asm/page.h +++ lnx-511-rc1/arch/arc/include/asm/page.h @@ -10,6 +10,7 @@ #ifndef __ASSEMBLY__ #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from) #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE) struct vm_area_struct; ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2] fs/dax: include to fix build error on ARC
On 1/4/21 12:13 PM, Dan Williams wrote:
> On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
>>
>> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
>> resulting in a build error.
>>
>> Provide copy_user_page() in (beside copy_page()) and
>> add to fs/dax.c to fix the build error.
>>
>> ../fs/dax.c: In function 'copy_cow_page_dax':
>> ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page';
>> did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration]
>>
>> Fixes: cccbce671582 ("filesystem-dax: convert to dax_direct_access()")
>> Reported-by: kernel test robot
>> Signed-off-by: Randy Dunlap
>> Cc: Vineet Gupta
>> Cc: linux-snps-...@lists.infradead.org
>> Cc: Dan Williams
>> Acked-by: Vineet Gupta
>> Cc: Andrew Morton
>> Cc: Matthew Wilcox
>> Cc: Jan Kara
>> Cc: linux-fsde...@vger.kernel.org
>> Cc: linux-nvdimm@lists.01.org
>> ---
>> v2: rebase, add more Cc:
>>
>> arch/arc/include/asm/page.h |1 +
>> fs/dax.c|1 +
>> 2 files changed, 2 insertions(+)
>>
>> --- lnx-511-rc1.orig/fs/dax.c
>> +++ lnx-511-rc1/fs/dax.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>
> I would expect this to come from one of the linux/ includes like
> linux/mm.h. asm/ headers are implementation linux/ headers are api.
>
> Once you drop that then the subject of this patch can just be "arc:
> add a copy_user_page() implementation", and handled by the arc
> maintainer (or I can take it with Vineet's ack).
Got it. Thanks.
Vineet is copied. I expect that he will take the v3 patch.
>> #include
>
> Yes, this one should have a linux/ api header to front it, but that's
> a cleanup for another day.
That line is only part of the contextual diff in this patch.
I guess you are just commenting in general, along with your earlier
paragraph.
>>
>> #define CREATE_TRACE_POINTS
>> --- lnx-511-rc1.orig/arch/arc/include/asm/page.h
>> +++ lnx-511-rc1/arch/arc/include/asm/page.h
>> @@ -10,6 +10,7 @@
>> #ifndef __ASSEMBLY__
>>
>> #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE)
>> +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from)
>> #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE)
>>
>> struct vm_area_struct;
--
~Randy
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] libnvdimm/pmem: remove unused header.
On Mon, Jan 04, 2021 at 02:32:06PM -0800, Dan Williams wrote:
> On Mon, Jan 4, 2021 at 2:19 PM Ira Weiny wrote:
> >
> > On Mon, Jan 04, 2021 at 01:16:32PM -0800, Dan Williams wrote:
> > > On Mon, Dec 28, 2020 at 9:18 AM Ira Weiny wrote:
> > > >
> > > > On Fri, Dec 25, 2020 at 09:35:46AM +0800, Jianpeng Ma wrote:
> > > > > 'commit a8b456d01cd6 ("bdi: remove BDI_CAP_SYNCHRONOUS_IO")' forgot
> > > >
> > > > This information should be part of a fixes tag.
> > >
> > > Oh, I was just about to comment "don't provide a Fixes tag for pure
> > > cleanups". Fixes is for functional issues that a backporter should
> > > consider.
> >
> > I thought this was discussed recently and it was concluded that 'fixes' does
> > not indicate something should be backported?
> >
> > ...
> >
> > https://lore.kernel.org/lkml/x8flmvawl0158...@kroah.com/
> >
> > At least that is what Greg KH said. But Dave C. was not happy with this...
>
> I was thinking of it more from the distro automation tooling that I
> know fires up it sees a "Fixes" tag. At a minimum this would make
> those systems / humans fire up just to notice, "oh, just a plain
> cleanup with no logical side-effects".
I'm not really following but I don't think it is a big deal either way. It
just seemed like the text used looked like a 'fixes' line and seemed ok to put
in there.
In this case it is probably fine.
Sorry for the noise,
Ira
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [RFC PATCH v3 8/9] md: Implement ->corrupted_range()
On Fri, Dec 18, 2020 at 10:11:54AM +0800, Ruan Shiyang wrote:
>
>
> On 2020/12/16 上午4:51, Darrick J. Wong wrote:
> > On Tue, Dec 15, 2020 at 08:14:13PM +0800, Shiyang Ruan wrote:
> > > With the support of ->rmap(), it is possible to obtain the superblock on
> > > a mapped device.
> > >
> > > If a pmem device is used as one target of mapped device, we cannot
> > > obtain its superblock directly. With the help of SYSFS, the mapped
> > > device can be found on the target devices. So, we iterate the
> > > bdev->bd_holder_disks to obtain its mapped device.
> > >
> > > Signed-off-by: Shiyang Ruan
> > > ---
> > > drivers/md/dm.c | 66 +++
> > > drivers/nvdimm/pmem.c | 9 --
> > > fs/block_dev.c| 21 ++
> > > include/linux/genhd.h | 7 +
> > > 4 files changed, 100 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> > > index 4e0cbfe3f14d..9da1f9322735 100644
> > > --- a/drivers/md/dm.c
> > > +++ b/drivers/md/dm.c
> > > @@ -507,6 +507,71 @@ static int dm_blk_report_zones(struct gendisk *disk,
> > > sector_t sector,
> > > #define dm_blk_report_zones NULL
> > > #endif /* CONFIG_BLK_DEV_ZONED */
> > > +struct dm_blk_corrupt {
> > > + struct block_device *bdev;
> > > + sector_t offset;
> > > +};
> > > +
> > > +static int dm_blk_corrupt_fn(struct dm_target *ti, struct dm_dev *dev,
> > > + sector_t start, sector_t len, void *data)
> > > +{
> > > + struct dm_blk_corrupt *bc = data;
> > > +
> > > + return bc->bdev == (void *)dev->bdev &&
> > > + (start <= bc->offset && bc->offset < start + len);
> > > +}
> > > +
> > > +static int dm_blk_corrupted_range(struct gendisk *disk,
> > > + struct block_device *target_bdev,
> > > + loff_t target_offset, size_t len, void *data)
> > > +{
> > > + struct mapped_device *md = disk->private_data;
> > > + struct block_device *md_bdev = md->bdev;
> > > + struct dm_table *map;
> > > + struct dm_target *ti;
> > > + struct super_block *sb;
> > > + int srcu_idx, i, rc = 0;
> > > + bool found = false;
> > > + sector_t disk_sec, target_sec = to_sector(target_offset);
> > > +
> > > + map = dm_get_live_table(md, &srcu_idx);
> > > + if (!map)
> > > + return -ENODEV;
> > > +
> > > + for (i = 0; i < dm_table_get_num_targets(map); i++) {
> > > + ti = dm_table_get_target(map, i);
> > > + if (ti->type->iterate_devices && ti->type->rmap) {
> > > + struct dm_blk_corrupt bc = {target_bdev, target_sec};
> > > +
> > > + found = ti->type->iterate_devices(ti,
> > > dm_blk_corrupt_fn, &bc);
> > > + if (!found)
> > > + continue;
> > > + disk_sec = ti->type->rmap(ti, target_sec);
> >
> > What happens if the dm device has multiple reverse mappings because the
> > physical storage is being shared at multiple LBAs? (e.g. a
> > deduplication target)
>
> I thought that the dm device knows the mapping relationship, and it can be
> done by implementation of ->rmap() in each target. Did I understand it
> wrong?
The dm device /does/ know the mapping relationship. I'm asking what
happens if there are *multiple* mappings. For example, a deduplicating
dm device could observe that the upper level code wrote some data to
sector 200 and now it wants to write the same data to sector 500.
Instead of writing twice, it simply maps sector 500 in its LBA space to
the same space that it mapped sector 200.
Pretend that sector 200 on the dm-dedupe device maps to sector 64 on the
underlying storage (call it /dev/pmem1 and let's say it's the only
target sitting underneath the dm-dedupe device).
If /dev/pmem1 then notices that sector 64 has gone bad, it will start
calling ->corrupted_range handlers until it calls dm_blk_corrupted_range
on the dm-dedupe device. At least in theory, the dm-dedupe driver's
rmap method ought to return both (64 -> 200) and (64 -> 500) so that
dm_blk_corrupted_range can pass on both corruption notices to whatever's
sitting atop the dedupe device.
At the moment, your ->rmap prototype is only capable of returning one
sector_t mapping per target, and there's only the one target under the
dedupe device, so we cannot report the loss of sectors 200 and 500 to
whatever device is sitting on top of dm-dedupe.
--D
> >
> > > + break;
> > > + }
> > > + }
> > > +
> > > + if (!found) {
> > > + rc = -ENODEV;
> > > + goto out;
> > > + }
> > > +
> > > + sb = get_super(md_bdev);
> > > + if (!sb) {
> > > + rc = bd_disk_holder_corrupted_range(md_bdev,
> > > to_bytes(disk_sec), len, data);
> > > + goto out;
> > > + } else if (sb->s_op->corrupted_range) {
> > > + loff_t off = to_bytes(disk_sec - get_start_sect(md_bdev));
> > > +
> > > + rc = sb->s_op->corrupted_range(sb, md_bdev, off, len, data);
> >
> >
Re: [PATCH 09/10] xfs: Implement ->corrupted_range() for XFS
On Thu, Dec 31, 2020 at 12:56:00AM +0800, Shiyang Ruan wrote:
> This function is used to handle errors which may cause data lost in
> filesystem. Such as memory failure in fsdax mode.
>
> In XFS, it requires "rmapbt" feature in order to query for files or
> metadata which associated to the corrupted data. Then we could call fs
> recover functions to try to repair the corrupted data.(did not
> implemented in this patchset)
>
> After that, the memory failure also needs to notify the processes who
> are using those files.
>
> Only support data device. Realtime device is not supported for now.
>
> Signed-off-by: Shiyang Ruan
> ---
> fs/xfs/xfs_fsops.c | 5 +++
> fs/xfs/xfs_mount.h | 1 +
> fs/xfs/xfs_super.c | 107 +
> 3 files changed, 113 insertions(+)
>
> diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
> index ef1d5bb88b93..0a2038875d32 100644
> --- a/fs/xfs/xfs_fsops.c
> +++ b/fs/xfs/xfs_fsops.c
> @@ -501,6 +501,11 @@ xfs_do_force_shutdown(
> "Corruption of in-memory data detected. Shutting down filesystem");
> if (XFS_ERRLEVEL_HIGH <= xfs_error_level)
> xfs_stack_trace();
> + } else if (flags & SHUTDOWN_CORRUPT_META) {
> + xfs_alert_tag(mp, XFS_PTAG_SHUTDOWN_CORRUPT,
> +"Corruption of on-disk metadata detected. Shutting down filesystem");
> + if (XFS_ERRLEVEL_HIGH <= xfs_error_level)
> + xfs_stack_trace();
> } else if (logerror) {
> xfs_alert_tag(mp, XFS_PTAG_SHUTDOWN_LOGERROR,
> "Log I/O Error Detected. Shutting down filesystem");
> diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> index dfa429b77ee2..8f0df67ffcc1 100644
> --- a/fs/xfs/xfs_mount.h
> +++ b/fs/xfs/xfs_mount.h
> @@ -274,6 +274,7 @@ void xfs_do_force_shutdown(struct xfs_mount *mp, int
> flags, char *fname,
> #define SHUTDOWN_LOG_IO_ERROR0x0002 /* write attempt to the log
> failed */
> #define SHUTDOWN_FORCE_UMOUNT0x0004 /* shutdown from a forced
> unmount */
> #define SHUTDOWN_CORRUPT_INCORE 0x0008 /* corrupt in-memory data
> structures */
> +#define SHUTDOWN_CORRUPT_META0x0010 /* corrupt metadata on device */
>
> /*
> * Flags for xfs_mountfs
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index e3e229e52512..cbcad419bb9e 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -35,6 +35,11 @@
> #include "xfs_refcount_item.h"
> #include "xfs_bmap_item.h"
> #include "xfs_reflink.h"
> +#include "xfs_alloc.h"
> +#include "xfs_rmap.h"
> +#include "xfs_rmap_btree.h"
> +#include "xfs_rtalloc.h"
> +#include "xfs_bit.h"
>
> #include
> #include
> @@ -1103,6 +1108,107 @@ xfs_fs_free_cached_objects(
> return xfs_reclaim_inodes_nr(XFS_M(sb), sc->nr_to_scan);
> }
>
> +static int
> +xfs_corrupt_helper(
> + struct xfs_btree_cur*cur,
> + struct xfs_rmap_irec*rec,
> + void*data)
> +{
> + struct xfs_inode*ip;
> + struct address_space*mapping;
> + int rc = 0;
> + int *flags = data;
> +
> + if (XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) ||
> + (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK))) {
> + // TODO check and try to fix metadata
> + rc = -EFSCORRUPTED;
> + } else {
> + /*
> + * Get files that incore, filter out others that are not in use.
> + */
> + rc = xfs_iget(cur->bc_mp, cur->bc_tp, rec->rm_owner,
> + XFS_IGET_INCORE, 0, &ip);
> + if (rc || !ip)
> + return rc;
> + if (!VFS_I(ip)->i_mapping)
> + goto out;
> +
> + mapping = VFS_I(ip)->i_mapping;
> + if (IS_DAX(VFS_I(ip)))
> + rc = mf_dax_mapping_kill_procs(mapping, rec->rm_offset,
> +*flags);
> + else
> + mapping_set_error(mapping, -EFSCORRUPTED);
Hm. I don't know if EFSCORRUPTED is the right error code for corrupt
file data, since we (so far) have only used it for corrupt metadata.
> +
> + // TODO try to fix data
> +out:
> + xfs_irele(ip);
> + }
> +
> + return rc;
> +}
> +
> +static int
> +xfs_fs_corrupted_range(
> + struct super_block *sb,
> + struct block_device *bdev,
> + loff_t offset,
> + size_t len,
> + void*data)
> +{
> + struct xfs_mount*mp = XFS_M(sb);
> + struct xfs_trans*tp = NULL;
> + struct xfs_btree_cur*cur = NULL;
> + struct xfs_rmap_irecrmap_low, rmap_high;
> + struct xfs_buf *agf_bp = NULL;
> + xfs_fsblock_t fsbno = XFS_B_TO_FSB(mp, offset);
> + xfs_filblk
Re: [PATCH] libnvdimm/pmem: remove unused header.
On Mon, Jan 4, 2021 at 2:19 PM Ira Weiny wrote:
>
> On Mon, Jan 04, 2021 at 01:16:32PM -0800, Dan Williams wrote:
> > On Mon, Dec 28, 2020 at 9:18 AM Ira Weiny wrote:
> > >
> > > On Fri, Dec 25, 2020 at 09:35:46AM +0800, Jianpeng Ma wrote:
> > > > 'commit a8b456d01cd6 ("bdi: remove BDI_CAP_SYNCHRONOUS_IO")' forgot
> > >
> > > This information should be part of a fixes tag.
> >
> > Oh, I was just about to comment "don't provide a Fixes tag for pure
> > cleanups". Fixes is for functional issues that a backporter should
> > consider.
>
> I thought this was discussed recently and it was concluded that 'fixes' does
> not indicate something should be backported?
>
> ...
>
> https://lore.kernel.org/lkml/x8flmvawl0158...@kroah.com/
>
> At least that is what Greg KH said. But Dave C. was not happy with this...
I was thinking of it more from the distro automation tooling that I
know fires up it sees a "Fixes" tag. At a minimum this would make
those systems / humans fire up just to notice, "oh, just a plain
cleanup with no logical side-effects".
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] libnvdimm/pmem: remove unused header.
On Mon, Jan 04, 2021 at 01:16:32PM -0800, Dan Williams wrote:
> On Mon, Dec 28, 2020 at 9:18 AM Ira Weiny wrote:
> >
> > On Fri, Dec 25, 2020 at 09:35:46AM +0800, Jianpeng Ma wrote:
> > > 'commit a8b456d01cd6 ("bdi: remove BDI_CAP_SYNCHRONOUS_IO")' forgot
> >
> > This information should be part of a fixes tag.
>
> Oh, I was just about to comment "don't provide a Fixes tag for pure
> cleanups". Fixes is for functional issues that a backporter should
> consider.
I thought this was discussed recently and it was concluded that 'fixes' does
not indicate something should be backported?
...
https://lore.kernel.org/lkml/x8flmvawl0158...@kroah.com/
At least that is what Greg KH said. But Dave C. was not happy with this...
:-/
Sorry...
Ira
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] libnvdimm/pmem: remove unused header.
On Mon, Dec 28, 2020 at 9:18 AM Ira Weiny wrote:
>
> On Fri, Dec 25, 2020 at 09:35:46AM +0800, Jianpeng Ma wrote:
> > 'commit a8b456d01cd6 ("bdi: remove BDI_CAP_SYNCHRONOUS_IO")' forgot
>
> This information should be part of a fixes tag.
Oh, I was just about to comment "don't provide a Fixes tag for pure
cleanups". Fixes is for functional issues that a backporter should
consider.
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2] fs/dax: include to fix build error on ARC
On Mon, Jan 04, 2021 at 12:13:02PM -0800, Dan Williams wrote: > On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote: > > +++ lnx-511-rc1/fs/dax.c > > @@ -25,6 +25,7 @@ > > #include > > #include > > #include > > +#include > > I would expect this to come from one of the linux/ includes like > linux/mm.h. asm/ headers are implementation linux/ headers are api. It does indeed come from linux/mm.h already. And a number of other random places, including linux/serial.h. Our headers are a mess, but they shouldn't be made worse by adding _this_ include. So I second Dan's objection here. > Once you drop that then the subject of this patch can just be "arc: > add a copy_user_page() implementation", and handled by the arc > maintainer (or I can take it with Vineet's ack). > > > #include > > Yes, this one should have a linux/ api header to front it, but that's > a cleanup for another day. Definitely more involved. ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2] fs/dax: include to fix build error on ARC
On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
>
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in (beside copy_page()) and
> add to fs/dax.c to fix the build error.
>
> ../fs/dax.c: In function 'copy_cow_page_dax':
> ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page';
> did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration]
>
> Fixes: cccbce671582 ("filesystem-dax: convert to dax_direct_access()")
> Reported-by: kernel test robot
> Signed-off-by: Randy Dunlap
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
> Cc: Dan Williams
> Acked-by: Vineet Gupta
> Cc: Andrew Morton
> Cc: Matthew Wilcox
> Cc: Jan Kara
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-nvdimm@lists.01.org
> ---
> v2: rebase, add more Cc:
>
> arch/arc/include/asm/page.h |1 +
> fs/dax.c|1 +
> 2 files changed, 2 insertions(+)
>
> --- lnx-511-rc1.orig/fs/dax.c
> +++ lnx-511-rc1/fs/dax.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
I would expect this to come from one of the linux/ includes like
linux/mm.h. asm/ headers are implementation linux/ headers are api.
Once you drop that then the subject of this patch can just be "arc:
add a copy_user_page() implementation", and handled by the arc
maintainer (or I can take it with Vineet's ack).
> #include
Yes, this one should have a linux/ api header to front it, but that's
a cleanup for another day.
>
> #define CREATE_TRACE_POINTS
> --- lnx-511-rc1.orig/arch/arc/include/asm/page.h
> +++ lnx-511-rc1/arch/arc/include/asm/page.h
> @@ -10,6 +10,7 @@
> #ifndef __ASSEMBLY__
>
> #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE)
> +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from)
> #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE)
>
> struct vm_area_struct;
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2] fs/dax: include to fix build error on ARC
On Thu, Dec 31, 2020 at 08:29:14PM -0800, Randy Dunlap wrote:
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in (beside copy_page()) and
> add to fs/dax.c to fix the build error.
>
> ../fs/dax.c: In function 'copy_cow_page_dax':
> ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page';
> did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration]
>
> Fixes: cccbce671582 ("filesystem-dax: convert to dax_direct_access()")
> Reported-by: kernel test robot
> Signed-off-by: Randy Dunlap
Looks reasonable
Reviewed-by: Ira Weiny
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
> Cc: Dan Williams
> Acked-by: Vineet Gupta
> Cc: Andrew Morton
> Cc: Matthew Wilcox
> Cc: Jan Kara
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-nvdimm@lists.01.org
> ---
> v2: rebase, add more Cc:
>
> arch/arc/include/asm/page.h |1 +
> fs/dax.c|1 +
> 2 files changed, 2 insertions(+)
>
> --- lnx-511-rc1.orig/fs/dax.c
> +++ lnx-511-rc1/fs/dax.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define CREATE_TRACE_POINTS
> --- lnx-511-rc1.orig/arch/arc/include/asm/page.h
> +++ lnx-511-rc1/arch/arc/include/asm/page.h
> @@ -10,6 +10,7 @@
> #ifndef __ASSEMBLY__
>
> #define clear_page(paddr)memset((paddr), 0, PAGE_SIZE)
> +#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
> #define copy_page(to, from) memcpy((to), (from), PAGE_SIZE)
>
> struct vm_area_struct;
> ___
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
