Re: [PATCH] fs/dax: Fix run_dax() missing prototype

2022-03-09 Thread Dan Williams
On Fri, Mar 4, 2022 at 12:38 PM wrote: > > From: Ira Weiny > > The function run_dax() was missing a prototype when compiling with > warnings. > > Add bus.h to fix this. > Always include the warning and the compiler in the changelog. I suspect you hit this with LLVM and not gcc? super.c has no

Re: [PATCH] fs/dax: Fix missing kdoc for dax_device

2022-03-09 Thread Dan Williams
On Fri, Mar 4, 2022 at 12:47 PM wrote: > > From: Ira Weiny > > struct dax_device has a member named ops which was undocumented. > > Add the kdoc. > Applied, but I fixed up the subject prefix to just "dax:" since this is shared between the fs-dax and device-dax.

Re: [PATCH v7 0/4] Add perf interface to expose nvdimm

2022-03-09 Thread Dan Williams
On Mon, Mar 7, 2022 at 9:27 PM kajoljain wrote: > > Hi Dan, > Can you take this patch-set if it looks fine to you. > Pushed out to my libnvdimm-pending branch for a 0day confirmation before heading over to linux-next.

Re: [PATCH 05/11] cxl/core: Introduce cxl_set_lock_class()

2022-03-09 Thread Dan Williams
On Wed, Mar 9, 2022 at 10:33 AM Jonathan Cameron wrote: > > On Mon, 28 Feb 2022 18:49:17 -0800 > Dan Williams wrote: > > > Update CONFIG_PROVE_CXL_LOCKING to use the common device-core helpers > > for device_lock validation. > > > > When CONFIG_PROVE_LOCKING is enabled and

Re: [PATCH 03/11] cxl/core: Remove cxl_device_lock()

2022-03-09 Thread Dan Williams
On Wed, Mar 9, 2022 at 10:22 AM Jonathan Cameron wrote: > > On Mon, 28 Feb 2022 18:49:06 -0800 > Dan Williams wrote: > > > In preparation for moving lockdep_mutex nested lock acquisition into the > > core, remove the cxl_device_lock() wrapper, but preserve > > cxl_lock_class() that will be used

Re: [PATCH v4 6/6] mm: remove range parameter from follow_invalidate_pte()

2022-03-09 Thread Dan Williams
On Wed, Mar 2, 2022 at 12:30 AM Muchun Song wrote: > > The only user (DAX) of range parameter of follow_invalidate_pte() > is gone, it safe to remove the range paramter and make it static > to simlify the code. > Looks good, I suspect this savings is still valid if the "just use

Re: [PATCH v4 5/6] dax: fix missing writeprotect the pte entry

2022-03-09 Thread Dan Williams
On Wed, Mar 2, 2022 at 12:30 AM Muchun Song wrote: > > Currently dax_mapping_entry_mkclean() fails to clean and write protect > the pte entry within a DAX PMD entry during an *sync operation. This > can result in data loss in the following sequence: > > 1) process A mmap write to DAX PMD,

Re: [PATCH v4 3/6] mm: rmap: introduce pfn_mkclean_range() to cleans PTEs

2022-03-09 Thread Dan Williams
On Wed, Mar 9, 2022 at 4:26 PM Dan Williams wrote: > > On Wed, Mar 2, 2022 at 12:29 AM Muchun Song wrote: > > > > The page_mkclean_one() is supposed to be used with the pfn that has a > > associated struct page, but not all the pfns (e.g. DAX) have a struct > > page. Introduce a new function

Re: [PATCH v4 3/6] mm: rmap: introduce pfn_mkclean_range() to cleans PTEs

2022-03-09 Thread Dan Williams
On Wed, Mar 2, 2022 at 12:29 AM Muchun Song wrote: > > The page_mkclean_one() is supposed to be used with the pfn that has a > associated struct page, but not all the pfns (e.g. DAX) have a struct > page. Introduce a new function pfn_mkclean_range() to cleans the PTEs > (including PMDs) mapped

Re: [PATCH v4 2/6] dax: fix cache flush on PMD-mapped pages

2022-03-09 Thread Dan Williams
On Wed, Mar 2, 2022 at 12:29 AM Muchun Song wrote: > > The flush_cache_page() only remove a PAGE_SIZE sized range from the cache. > However, it does not cover the full pages in a THP except a head page. > Replace it with flush_cache_range() to fix this issue. This needs to clarify that this is

Re: [PATCH v4 1/6] mm: rmap: fix cache flush on THP pages

2022-03-09 Thread Dan Williams
On Wed, Mar 2, 2022 at 12:29 AM Muchun Song wrote: > > The flush_cache_page() only remove a PAGE_SIZE sized range from the cache. > However, it does not cover the full pages in a THP except a head page. > Replace it with flush_cache_range() to fix this issue. At least, no > problems were found

Re: [PATCH 04/11] cxl/core: Clamp max lock_class

2022-03-09 Thread Dan Williams
On Wed, Mar 9, 2022 at 10:27 AM Jonathan Cameron wrote: > > On Mon, 28 Feb 2022 18:49:11 -0800 > Dan Williams wrote: > > > MAX_LOCKDEP_SUBCLASSES limits the depth of the CXL topology that can be > > validated by lockdep. Given that the cxl_test topology is already at > > this limit collapse some

Re: [PATCH 02/11] cxl/core: Refactor a cxl_lock_class() out of cxl_nested_lock()

2022-03-09 Thread Dan Williams
On Wed, Mar 9, 2022 at 10:19 AM Jonathan Cameron wrote: > > On Mon, 28 Feb 2022 18:49:00 -0800 > Dan Williams wrote: > > > In preparation for upleveling device_lock() lockdep annotation support into > > the core, provide a helper to retrieve the lock class. This lock_class > > will be used with