Linux Device Mapper development
 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: 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: Fri, 22 Oct 2021 16:03:20 +0800	[thread overview]
Message-ID: <202110221647.sUItp6Ad-lkp@intel.com> (raw)
In-Reply-To: <20211021001059.438843-6-jane.chu@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 5335 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 nvdimm/libnvdimm-for-next mszeredi-fuse/for-next linus/master v5.15-rc6 next-20211021]
[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-debian-10.3 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # 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
        make 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 >>):

   In file included from include/linux/device.h:15,
                    from include/linux/blk_types.h:11,
                    from include/linux/genhd.h:19,
                    from include/linux/blkdev.h:8,
                    from drivers/nvdimm/pmem.c:10:
   drivers/nvdimm/pmem.c: In function 'pmem_copy_from_iter':
>> drivers/nvdimm/pmem.c:336:19: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
     336 |     dev_warn(dev, "Found poison, but addr(%p) and/or bytes(%#lx) not page aligned\n",
         |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/dev_printk.h:110:16: note: in definition of macro 'dev_printk_index_wrap'
     110 |   _p_func(dev, fmt, ##__VA_ARGS__);   \
         |                ^~~
   include/linux/dev_printk.h:146:54: note: in expansion of macro 'dev_fmt'
     146 |  dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
         |                                                      ^~~~~~~
   drivers/nvdimm/pmem.c:336:5: note: in expansion of macro 'dev_warn'
     336 |     dev_warn(dev, "Found poison, but addr(%p) and/or bytes(%#lx) not page aligned\n",
         |     ^~~~~~~~
   drivers/nvdimm/pmem.c:336:63: note: format string is defined here
     336 |     dev_warn(dev, "Found poison, but addr(%p) and/or bytes(%#lx) not page aligned\n",
         |                                                            ~~~^
         |                                                               |
         |                                                               long unsigned int
         |                                                            %#x


vim +336 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: 38478 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

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

Thread overview: 64+ 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 ` [dm-devel] [PATCH 1/6] dax: introduce RWF_RECOVERY_DATA flag to preadv2() and pwritev2() 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 11:20   ` Christoph Hellwig
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 11:23   ` Christoph Hellwig
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 11:27   ` Christoph Hellwig
2021-10-22  0:49     ` Jane Chu
2021-10-22  1:41       ` [dm-devel] correction: " Jane Chu
2021-10-22  5:33       ` [dm-devel] " Christoph Hellwig
2021-10-22 20:30         ` 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 11:28   ` Christoph Hellwig
2021-10-22  0:58     ` Jane Chu
2021-10-22  8:03   ` kernel test robot [this message]
2021-10-26 10:21   ` 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 11:31 ` [dm-devel] [PATCH 0/6] dax poison recovery with RWF_RECOVERY_DATA flag Christoph Hellwig
2021-10-22  1:37   ` Jane Chu
2021-10-22  1:58     ` Darrick J. Wong
2021-10-22  5:38       ` Christoph Hellwig
2021-10-22  5:36     ` Christoph Hellwig
2021-10-22 20:52       ` Jane Chu
2021-10-27  6:49         ` Christoph Hellwig
2021-10-28  0:24           ` Darrick J. Wong
2021-10-28 22:59             ` Dave Chinner
2021-10-29 11:46               ` Pavel Begunkov
2021-10-29 16:57                 ` Darrick J. Wong
2021-10-29 19:23                   ` Pavel Begunkov
2021-10-29 20:08                     ` Darrick J. Wong
2021-10-31 13:27                       ` Pavel Begunkov
2021-10-29 18:53                 ` Jane Chu
2021-10-29 22:32                 ` Dave Chinner
2021-10-31 13:19                   ` Pavel Begunkov
2021-11-01  2:31                     ` Matthew Wilcox
2021-11-02  6:18             ` Christoph Hellwig
2021-11-02 19:57               ` Dan Williams
2021-11-03 16:58                 ` Christoph Hellwig
2021-11-03 20:33                   ` Dan Williams
2021-11-04  8:30                     ` Christoph Hellwig
2021-11-04 12:29                       ` Matthew Wilcox
2021-11-04 16:24                       ` Dan Williams
2021-11-04 17:43                         ` Christoph Hellwig
2021-11-04 17:50                           ` Dan Williams
2021-11-04 18:05                           ` Matthew Wilcox
2021-11-04 18:33                         ` Jane Chu
2021-11-04 19:00                           ` Dan Williams
2021-11-04 20:27                             ` Jane Chu
2021-11-05  0:46                               ` Dan Williams
2021-11-05  1:35                                 ` Dan Williams
2021-11-05  5:56                             ` Christoph Hellwig
2021-11-03 18:09               ` Jane Chu
2021-11-04  6:21                 ` Dan Williams
2021-11-04  8:36                   ` Christoph Hellwig
2021-11-04 16:08                     ` Dan Williams
2021-11-04 17:46                       ` Christoph Hellwig
2021-11-04  8:21                 ` Christoph Hellwig
2021-11-02 16:12             ` Dan Williams
2021-11-02 16:03           ` Dan Williams
2021-11-03 16:53             ` Christoph Hellwig
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=202110221647.sUItp6Ad-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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox