[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4jz7-uq+T-sd_U3O_C7SB9nYWVJDnhVsaM0VNR207m8xA@mail.gmail.com>
Date: Thu, 11 Mar 2021 09:25:10 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: "chenjun (AM)" <chenjun102@...wei.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Jan Kara <jack@...e.cz>,
"Xiangrui (Euler)" <rui.xiang@...wei.com>,
"lizhe (Y)" <lizhe67@...wei.com>, yangerkun <yangerkun@...wei.com>,
"zhangyi (F)" <yi.zhang@...wei.com>
Subject: Re: [question] Panic in dax_writeback_one
On Thu, Mar 11, 2021 at 4:20 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Thu, Mar 11, 2021 at 07:48:25AM +0000, chenjun (AM) wrote:
> > static int dax_writeback_one(struct xa_state *xas, struct dax_device
> > *dax_dev, struct address_space *mapping, void *entry)
> > ----dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE);
> > The pfn is returned by the driver. In my case, the pfn does not have
> > struct page. so pfn_to_page(pfn) return a wrong address.
>
> I wasn't involved, but I think the right solution here is simply to
> replace page_address(pfn_to_page(pfn)) with pfn_to_virt(pfn). I don't
> know why Dan decided to do this in the more complicated way.
pfn_to_virt() only works for the direct-map. If pages are not mapped I
don't see how pfn_to_virt() is expected to work.
The real question Chenjun is why are you writing a new simulator of
memory as a block-device vs reusing the pmem driver or brd?
Powered by blists - more mailing lists