All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Jane Chu <jane.chu@oracle.com>,
	david@fromorbit.com, djwong@kernel.org, dan.j.williams@intel.com,
	hch@infradead.org, vishal.l.verma@intel.com,
	 dave.jiang@intel.com, agk@redhat.com, snitzer@redhat.com,
	dm-devel@redhat.com, ira.weiny@intel.com
Cc: llvm@lists.linux.dev, kbuild-all@lists.01.org
Subject: Re: [dm-devel] [PATCH 5/6] dax, pmem: Add data recovery feature to pmem_copy_to/from_iter()
Date: Tue, 26 Oct 2021 18:21:21 +0800	[thread overview]
Message-ID: <202110261846.21CD3Tod-lkp@intel.com> (raw)
In-Reply-To: <20211021001059.438843-6-jane.chu@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 4577 bytes --]

Hi Jane,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on device-mapper-dm/for-next]
[also build test WARNING on mszeredi-fuse/for-next linus/master v5.15-rc7 next-20211025]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Jane-Chu/dax-poison-recovery-with-RWF_RECOVERY_DATA-flag/20211021-081336
base:   https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git for-next
config: i386-randconfig-a013-20211022 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 5dc339d9825f1dbe788cfb69c88210a59bbf8e3a)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/a01994a484c54b2f4b6eb32104ab3caf7b9b32a8
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Jane-Chu/dax-poison-recovery-with-RWF_RECOVERY_DATA-flag/20211021-081336
        git checkout a01994a484c54b2f4b6eb32104ab3caf7b9b32a8
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/nvdimm/pmem.c:337:12: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
                                           addr, bytes);
                                                 ^~~~~
   include/linux/dev_printk.h:146:70: note: expanded from macro 'dev_warn'
           dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
                                                                       ~~~     ^~~~~~~~~~~
   include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
                   _p_func(dev, fmt, ##__VA_ARGS__);                       \
                                ~~~    ^~~~~~~~~~~
   1 warning generated.


vim +337 drivers/nvdimm/pmem.c

   306	
   307	/*
   308	 * Even though the 'no check' versions of copy_from_iter_flushcache()
   309	 * and copy_mc_to_iter() are used to bypass HARDENED_USERCOPY overhead,
   310	 * 'read'/'write' aren't always safe when poison is consumed. They happen
   311	 * to be safe because the 'read'/'write' range has been guaranteed
   312	 * be free of poison(s) by a prior call to dax_direct_access() on the
   313	 * caller stack.
   314	 * However with the introduction of DAXDEV_F_RECOVERY, the 'read'/'write'
   315	 * range may contain poison(s), so the functions perform explicit check
   316	 * on poison, and 'read' end up fetching only non-poisoned page(s) up
   317	 * till  the first poison is encountered while 'write' require the range
   318	 * is page aligned in order to restore the poisoned page's memory type
   319	 * back to "rw" after clearing the poison(s).
   320	 * In the event of poison related failure, (size_t) -EIO is returned and
   321	 * caller may check the return value after casting it to (ssize_t).
   322	 */
   323	static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff,
   324		void *addr, size_t bytes, struct iov_iter *i, unsigned long flags)
   325	{
   326		phys_addr_t pmem_off;
   327		size_t len, lead_off;
   328		struct pmem_device *pmem = dax_get_private(dax_dev);
   329		struct device *dev = pmem->bb.dev;
   330	
   331		if (flags & DAXDEV_F_RECOVERY) {
   332			lead_off = (unsigned long)addr & ~PAGE_MASK;
   333			len = PFN_PHYS(PFN_UP(lead_off + bytes));
   334			if (is_bad_pmem(&pmem->bb, PFN_PHYS(pgoff) / 512, len)) {
   335				if (lead_off || !(PAGE_ALIGNED(bytes))) {
   336					dev_warn(dev, "Found poison, but addr(%p) and/or bytes(%#lx) not page aligned\n",
 > 337						addr, bytes);
   338					return (size_t) -EIO;
   339				}
   340				pmem_off = PFN_PHYS(pgoff) + pmem->data_offset;
   341				if (pmem_clear_poison(pmem, pmem_off, bytes) !=
   342						BLK_STS_OK)
   343					return (size_t) -EIO;
   344			}
   345		}
   346	
   347		return _copy_from_iter_flushcache(addr, bytes, i);
   348	}
   349	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 41075 bytes --]

[-- Attachment #3: Type: text/plain, Size: 97 bytes --]

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: Jane Chu <jane.chu@oracle.com>,
	david@fromorbit.com, djwong@kernel.org, dan.j.williams@intel.com,
	hch@infradead.org, vishal.l.verma@intel.com,
	dave.jiang@intel.com, agk@redhat.com, snitzer@redhat.com,
	dm-devel@redhat.com, ira.weiny@intel.com
Cc: llvm@lists.linux.dev, kbuild-all@lists.01.org
Subject: Re: [PATCH 5/6] dax,pmem: Add data recovery feature to pmem_copy_to/from_iter()
Date: Tue, 26 Oct 2021 18:21:21 +0800	[thread overview]
Message-ID: <202110261846.21CD3Tod-lkp@intel.com> (raw)
In-Reply-To: <20211021001059.438843-6-jane.chu@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 4577 bytes --]

Hi Jane,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on device-mapper-dm/for-next]
[also build test WARNING on mszeredi-fuse/for-next linus/master v5.15-rc7 next-20211025]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Jane-Chu/dax-poison-recovery-with-RWF_RECOVERY_DATA-flag/20211021-081336
base:   https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git for-next
config: i386-randconfig-a013-20211022 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 5dc339d9825f1dbe788cfb69c88210a59bbf8e3a)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/a01994a484c54b2f4b6eb32104ab3caf7b9b32a8
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Jane-Chu/dax-poison-recovery-with-RWF_RECOVERY_DATA-flag/20211021-081336
        git checkout a01994a484c54b2f4b6eb32104ab3caf7b9b32a8
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/nvdimm/pmem.c:337:12: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
                                           addr, bytes);
                                                 ^~~~~
   include/linux/dev_printk.h:146:70: note: expanded from macro 'dev_warn'
           dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
                                                                       ~~~     ^~~~~~~~~~~
   include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
                   _p_func(dev, fmt, ##__VA_ARGS__);                       \
                                ~~~    ^~~~~~~~~~~
   1 warning generated.


vim +337 drivers/nvdimm/pmem.c

   306	
   307	/*
   308	 * Even though the 'no check' versions of copy_from_iter_flushcache()
   309	 * and copy_mc_to_iter() are used to bypass HARDENED_USERCOPY overhead,
   310	 * 'read'/'write' aren't always safe when poison is consumed. They happen
   311	 * to be safe because the 'read'/'write' range has been guaranteed
   312	 * be free of poison(s) by a prior call to dax_direct_access() on the
   313	 * caller stack.
   314	 * However with the introduction of DAXDEV_F_RECOVERY, the 'read'/'write'
   315	 * range may contain poison(s), so the functions perform explicit check
   316	 * on poison, and 'read' end up fetching only non-poisoned page(s) up
   317	 * till  the first poison is encountered while 'write' require the range
   318	 * is page aligned in order to restore the poisoned page's memory type
   319	 * back to "rw" after clearing the poison(s).
   320	 * In the event of poison related failure, (size_t) -EIO is returned and
   321	 * caller may check the return value after casting it to (ssize_t).
   322	 */
   323	static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff,
   324		void *addr, size_t bytes, struct iov_iter *i, unsigned long flags)
   325	{
   326		phys_addr_t pmem_off;
   327		size_t len, lead_off;
   328		struct pmem_device *pmem = dax_get_private(dax_dev);
   329		struct device *dev = pmem->bb.dev;
   330	
   331		if (flags & DAXDEV_F_RECOVERY) {
   332			lead_off = (unsigned long)addr & ~PAGE_MASK;
   333			len = PFN_PHYS(PFN_UP(lead_off + bytes));
   334			if (is_bad_pmem(&pmem->bb, PFN_PHYS(pgoff) / 512, len)) {
   335				if (lead_off || !(PAGE_ALIGNED(bytes))) {
   336					dev_warn(dev, "Found poison, but addr(%p) and/or bytes(%#lx) not page aligned\n",
 > 337						addr, bytes);
   338					return (size_t) -EIO;
   339				}
   340				pmem_off = PFN_PHYS(pgoff) + pmem->data_offset;
   341				if (pmem_clear_poison(pmem, pmem_off, bytes) !=
   342						BLK_STS_OK)
   343					return (size_t) -EIO;
   344			}
   345		}
   346	
   347		return _copy_from_iter_flushcache(addr, bytes, i);
   348	}
   349	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 41075 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH 5/6] dax, pmem: Add data recovery feature to pmem_copy_to/from_iter()
Date: Tue, 26 Oct 2021 18:21:21 +0800	[thread overview]
Message-ID: <202110261846.21CD3Tod-lkp@intel.com> (raw)
In-Reply-To: <20211021001059.438843-6-jane.chu@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 4670 bytes --]

Hi Jane,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on device-mapper-dm/for-next]
[also build test WARNING on mszeredi-fuse/for-next linus/master v5.15-rc7 next-20211025]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Jane-Chu/dax-poison-recovery-with-RWF_RECOVERY_DATA-flag/20211021-081336
base:   https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git for-next
config: i386-randconfig-a013-20211022 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 5dc339d9825f1dbe788cfb69c88210a59bbf8e3a)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/a01994a484c54b2f4b6eb32104ab3caf7b9b32a8
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Jane-Chu/dax-poison-recovery-with-RWF_RECOVERY_DATA-flag/20211021-081336
        git checkout a01994a484c54b2f4b6eb32104ab3caf7b9b32a8
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/nvdimm/pmem.c:337:12: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
                                           addr, bytes);
                                                 ^~~~~
   include/linux/dev_printk.h:146:70: note: expanded from macro 'dev_warn'
           dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
                                                                       ~~~     ^~~~~~~~~~~
   include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
                   _p_func(dev, fmt, ##__VA_ARGS__);                       \
                                ~~~    ^~~~~~~~~~~
   1 warning generated.


vim +337 drivers/nvdimm/pmem.c

   306	
   307	/*
   308	 * Even though the 'no check' versions of copy_from_iter_flushcache()
   309	 * and copy_mc_to_iter() are used to bypass HARDENED_USERCOPY overhead,
   310	 * 'read'/'write' aren't always safe when poison is consumed. They happen
   311	 * to be safe because the 'read'/'write' range has been guaranteed
   312	 * be free of poison(s) by a prior call to dax_direct_access() on the
   313	 * caller stack.
   314	 * However with the introduction of DAXDEV_F_RECOVERY, the 'read'/'write'
   315	 * range may contain poison(s), so the functions perform explicit check
   316	 * on poison, and 'read' end up fetching only non-poisoned page(s) up
   317	 * till  the first poison is encountered while 'write' require the range
   318	 * is page aligned in order to restore the poisoned page's memory type
   319	 * back to "rw" after clearing the poison(s).
   320	 * In the event of poison related failure, (size_t) -EIO is returned and
   321	 * caller may check the return value after casting it to (ssize_t).
   322	 */
   323	static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff,
   324		void *addr, size_t bytes, struct iov_iter *i, unsigned long flags)
   325	{
   326		phys_addr_t pmem_off;
   327		size_t len, lead_off;
   328		struct pmem_device *pmem = dax_get_private(dax_dev);
   329		struct device *dev = pmem->bb.dev;
   330	
   331		if (flags & DAXDEV_F_RECOVERY) {
   332			lead_off = (unsigned long)addr & ~PAGE_MASK;
   333			len = PFN_PHYS(PFN_UP(lead_off + bytes));
   334			if (is_bad_pmem(&pmem->bb, PFN_PHYS(pgoff) / 512, len)) {
   335				if (lead_off || !(PAGE_ALIGNED(bytes))) {
   336					dev_warn(dev, "Found poison, but addr(%p) and/or bytes(%#lx) not page aligned\n",
 > 337						addr, bytes);
   338					return (size_t) -EIO;
   339				}
   340				pmem_off = PFN_PHYS(pgoff) + pmem->data_offset;
   341				if (pmem_clear_poison(pmem, pmem_off, bytes) !=
   342						BLK_STS_OK)
   343					return (size_t) -EIO;
   344			}
   345		}
   346	
   347		return _copy_from_iter_flushcache(addr, bytes, i);
   348	}
   349	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 41075 bytes --]

  parent reply	other threads:[~2021-10-26 10:22 UTC|newest]

Thread overview: 129+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21  0:10 [dm-devel] [PATCH 0/6] dax poison recovery with RWF_RECOVERY_DATA flag Jane Chu
2021-10-21  0:10 ` Jane Chu
2021-10-21  0:10 ` [dm-devel] [PATCH 1/6] dax: introduce RWF_RECOVERY_DATA flag to preadv2() and pwritev2() Jane Chu
2021-10-21  0:10   ` Jane Chu
2021-10-21  0:10 ` [dm-devel] [PATCH 2/6] dax: prepare dax_direct_access() API with DAXDEV_F_RECOVERY flag Jane Chu
2021-10-21  0:10   ` Jane Chu
2021-10-21 11:20   ` [dm-devel] " Christoph Hellwig
2021-10-21 11:20     ` Christoph Hellwig
2021-10-21 18:19     ` [dm-devel] " Jane Chu
2021-10-21 18:19       ` Jane Chu
2021-10-21  0:10 ` [dm-devel] [PATCH 3/6] pmem: pmem_dax_direct_access() to honor the " Jane Chu
2021-10-21  0:10   ` Jane Chu
2021-10-21 11:23   ` [dm-devel] " Christoph Hellwig
2021-10-21 11:23     ` Christoph Hellwig
2021-10-21 18:24     ` [dm-devel] " Jane Chu
2021-10-21 18:24       ` Jane Chu
2021-10-21  0:10 ` [dm-devel] [PATCH 4/6] dm, dax, pmem: prepare dax_copy_to/from_iter() APIs with DAXDEV_F_RECOVERY Jane Chu
2021-10-21  0:10   ` [PATCH 4/6] dm,dax,pmem: " Jane Chu
2021-10-21 11:27   ` [dm-devel] [PATCH 4/6] dm, dax, pmem: " Christoph Hellwig
2021-10-21 11:27     ` [PATCH 4/6] dm,dax,pmem: " Christoph Hellwig
2021-10-22  0:49     ` [dm-devel] [PATCH 4/6] dm, dax, pmem: " Jane Chu
2021-10-22  0:49       ` [PATCH 4/6] dm,dax,pmem: " Jane Chu
2021-10-22  1:41       ` [dm-devel] correction: Re: [PATCH 4/6] dm, dax, pmem: " Jane Chu
2021-10-22  1:41         ` correction: Re: [PATCH 4/6] dm,dax,pmem: " Jane Chu
2021-10-22  5:33       ` [dm-devel] [PATCH 4/6] dm, dax, pmem: " Christoph Hellwig
2021-10-22  5:33         ` [PATCH 4/6] dm,dax,pmem: " Christoph Hellwig
2021-10-22 20:30         ` [dm-devel] [PATCH 4/6] dm, dax, pmem: " Jane Chu
2021-10-22 20:30           ` [PATCH 4/6] dm,dax,pmem: " Jane Chu
2021-10-21  0:10 ` [dm-devel] [PATCH 5/6] dax, pmem: Add data recovery feature to pmem_copy_to/from_iter() Jane Chu
2021-10-21  0:10   ` [PATCH 5/6] dax,pmem: " Jane Chu
2021-10-21 11:28   ` [dm-devel] [PATCH 5/6] dax, pmem: " Christoph Hellwig
2021-10-21 11:28     ` [PATCH 5/6] dax,pmem: " Christoph Hellwig
2021-10-22  0:58     ` [dm-devel] [PATCH 5/6] dax, pmem: " Jane Chu
2021-10-22  0:58       ` [PATCH 5/6] dax,pmem: " Jane Chu
2021-10-22  8:03   ` [dm-devel] [PATCH 5/6] dax, pmem: " kernel test robot
2021-10-22  8:03     ` kernel test robot
2021-10-26 10:21   ` kernel test robot [this message]
2021-10-26 10:21     ` kernel test robot
2021-10-26 10:21     ` [PATCH 5/6] dax,pmem: " kernel test robot
2021-10-21  0:10 ` [dm-devel] [PATCH 6/6] dm: Ensure dm honors DAXDEV_F_RECOVERY flag on dax only Jane Chu
2021-10-21  0:10   ` Jane Chu
2021-10-21 11:31 ` [dm-devel] [PATCH 0/6] dax poison recovery with RWF_RECOVERY_DATA flag Christoph Hellwig
2021-10-21 11:31   ` Christoph Hellwig
2021-10-22  1:37   ` Jane Chu
2021-10-22  1:37     ` Jane Chu
2021-10-22  1:58     ` Darrick J. Wong
2021-10-22  1:58       ` Darrick J. Wong
2021-10-22  5:38       ` Christoph Hellwig
2021-10-22  5:38         ` Christoph Hellwig
2021-10-22  5:36     ` Christoph Hellwig
2021-10-22  5:36       ` Christoph Hellwig
2021-10-22 20:52       ` Jane Chu
2021-10-22 20:52         ` Jane Chu
2021-10-27  6:49         ` Christoph Hellwig
2021-10-27  6:49           ` Christoph Hellwig
2021-10-28  0:24           ` Darrick J. Wong
2021-10-28  0:24             ` Darrick J. Wong
2021-10-28 22:59             ` Dave Chinner
2021-10-28 22:59               ` Dave Chinner
2021-10-29 11:46               ` Pavel Begunkov
2021-10-29 11:46                 ` Pavel Begunkov
2021-10-29 16:57                 ` Darrick J. Wong
2021-10-29 16:57                   ` Darrick J. Wong
2021-10-29 19:23                   ` Pavel Begunkov
2021-10-29 19:23                     ` Pavel Begunkov
2021-10-29 20:08                     ` Darrick J. Wong
2021-10-29 20:08                       ` Darrick J. Wong
2021-10-31 13:27                       ` Pavel Begunkov
2021-10-31 13:27                         ` Pavel Begunkov
2021-10-29 18:53                 ` Jane Chu
2021-10-29 18:53                   ` Jane Chu
2021-10-29 22:32                 ` Dave Chinner
2021-10-29 22:32                   ` Dave Chinner
2021-10-31 13:19                   ` Pavel Begunkov
2021-10-31 13:19                     ` Pavel Begunkov
2021-11-01  2:31                     ` Matthew Wilcox
2021-11-01  2:31                       ` Matthew Wilcox
2021-11-02  6:18             ` Christoph Hellwig
2021-11-02  6:18               ` Christoph Hellwig
2021-11-02 19:57               ` Dan Williams
2021-11-02 19:57                 ` Dan Williams
2021-11-03 16:58                 ` Christoph Hellwig
2021-11-03 16:58                   ` Christoph Hellwig
2021-11-03 20:33                   ` Dan Williams
2021-11-03 20:33                     ` Dan Williams
2021-11-04  8:30                     ` Christoph Hellwig
2021-11-04  8:30                       ` Christoph Hellwig
2021-11-04 12:29                       ` Matthew Wilcox
2021-11-04 12:29                         ` Matthew Wilcox
2021-11-04 16:24                       ` Dan Williams
2021-11-04 16:24                         ` Dan Williams
2021-11-04 17:43                         ` Christoph Hellwig
2021-11-04 17:43                           ` Christoph Hellwig
2021-11-04 17:50                           ` Dan Williams
2021-11-04 17:50                             ` Dan Williams
2021-11-04 18:05                           ` Matthew Wilcox
2021-11-04 18:05                             ` Matthew Wilcox
2021-11-04 18:33                         ` Jane Chu
2021-11-04 18:33                           ` Jane Chu
2021-11-04 19:00                           ` Dan Williams
2021-11-04 19:00                             ` Dan Williams
2021-11-04 20:27                             ` Jane Chu
2021-11-04 20:27                               ` Jane Chu
2021-11-05  0:46                               ` Dan Williams
2021-11-05  0:46                                 ` Dan Williams
2021-11-05  1:35                                 ` Dan Williams
2021-11-05  1:35                                   ` Dan Williams
2021-11-05  5:56                             ` Christoph Hellwig
2021-11-05  5:56                               ` Christoph Hellwig
2021-11-03 18:09               ` Jane Chu
2021-11-03 18:09                 ` Jane Chu
2021-11-04  6:21                 ` Dan Williams
2021-11-04  6:21                   ` Dan Williams
2021-11-04  8:36                   ` Christoph Hellwig
2021-11-04  8:36                     ` Christoph Hellwig
2021-11-04 16:08                     ` Dan Williams
2021-11-04 16:08                       ` Dan Williams
2021-11-04 17:46                       ` Christoph Hellwig
2021-11-04 17:46                         ` Christoph Hellwig
2021-11-04  8:21                 ` Christoph Hellwig
2021-11-04  8:21                   ` Christoph Hellwig
2021-11-02 16:12             ` Dan Williams
2021-11-02 16:12               ` Dan Williams
2021-11-02 16:03           ` Dan Williams
2021-11-02 16:03             ` Dan Williams
2021-11-03 16:53             ` Christoph Hellwig
2021-11-03 16:53               ` Christoph Hellwig
2021-11-06  7:41             ` Lukas Straub
2021-11-06  7:41               ` Lukas Straub

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202110261846.21CD3Tod-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=agk@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=ira.weiny@intel.com \
    --cc=jane.chu@oracle.com \
    --cc=kbuild-all@lists.01.org \
    --cc=llvm@lists.linux.dev \
    --cc=snitzer@redhat.com \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.