All of lore.kernel.org
 help / color / mirror / Atom feed
From: kbuild test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH 4/8] btrfs: Switch to iomap_dio_rw() for dio
Date: Sat, 07 Dec 2019 19:57:29 +0800	[thread overview]
Message-ID: <201912071924.5kiMTl21%lkp@intel.com> (raw)
In-Reply-To: <20191205155630.28817-5-rgoldwyn@suse.de>

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

Hi Goldwyn,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v5.4-rc8]
[cannot apply to xfs-linux/for-next btrfs/next linus/master next-20191207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Goldwyn-Rodrigues/btrfs-direct-io-using-iomap/20191207-133923
base:    af42d3466bdc8f39806b26f593604fdc54140bcb
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.5.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.5.0 make.cross ARCH=sh 

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

All errors (new ones prefixed by >>):

>> fs//btrfs/inode.c:8631:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .iomap_begin            = btrfs_dio_iomap_begin,
                               ^~~~~~~~~~~~~~~~~~~~~
   fs//btrfs/inode.c:8631:28: note: (near initialization for 'btrfs_dio_iomap_ops.iomap_begin')
   fs//btrfs/inode.c: In function 'btrfs_direct_IO':
>> fs//btrfs/inode.c:8694:8: error: too many arguments to function 'iomap_dio_rw'
     ret = iomap_dio_rw(iocb, iter, &btrfs_dio_iomap_ops, &btrfs_dops,
           ^~~~~~~~~~~~
   In file included from fs//btrfs/inode.c:32:0:
   include/linux/iomap.h:199:9: note: declared here
    ssize_t iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
            ^~~~~~~~~~~~
   cc1: some warnings being treated as errors

vim +/iomap_dio_rw +8694 fs//btrfs/inode.c

  8629	
  8630	static const struct iomap_ops btrfs_dio_iomap_ops = {
> 8631		.iomap_begin            = btrfs_dio_iomap_begin,
  8632	};
  8633	
  8634	static const struct iomap_dio_ops btrfs_dops = {
  8635		.submit_io		= btrfs_submit_direct,
  8636	};
  8637	
  8638	
  8639	/*
  8640	 * btrfs_direct_IO - perform direct I/O
  8641	 * inode->i_rwsem must be locked before calling this function, shared or exclusive.
  8642	 * @iocb - kernel iocb
  8643	 * @iter - iter to/from data is copied
  8644	 */
  8645	
  8646	ssize_t btrfs_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
  8647	{
  8648		struct file *file = iocb->ki_filp;
  8649		struct inode *inode = file->f_mapping->host;
  8650		struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
  8651		struct btrfs_dio_data dio_data = { 0 };
  8652		struct extent_changeset *data_reserved = NULL;
  8653		loff_t offset = iocb->ki_pos;
  8654		size_t count = 0;
  8655		bool relock = false;
  8656		ssize_t ret;
  8657	
  8658		if (check_direct_IO(fs_info, iter, offset))
  8659			return 0;
  8660	
  8661		count = iov_iter_count(iter);
  8662		if (iov_iter_rw(iter) == WRITE) {
  8663			/*
  8664			 * If the write DIO is beyond the EOF, we need update
  8665			 * the isize, but it is protected by i_mutex. So we can
  8666			 * not unlock the i_mutex at this case.
  8667			 */
  8668			if (offset + count <= inode->i_size) {
  8669				dio_data.overwrite = 1;
  8670				inode_unlock(inode);
  8671				relock = true;
  8672			} else if (iocb->ki_flags & IOCB_NOWAIT) {
  8673				ret = -EAGAIN;
  8674				goto out;
  8675			}
  8676			ret = btrfs_delalloc_reserve_space(inode, &data_reserved,
  8677							   offset, count);
  8678			if (ret)
  8679				goto out;
  8680	
  8681			/*
  8682			 * We need to know how many extents we reserved so that we can
  8683			 * do the accounting properly if we go over the number we
  8684			 * originally calculated.  Abuse current->journal_info for this.
  8685			 */
  8686			dio_data.reserve = round_up(count,
  8687						    fs_info->sectorsize);
  8688			dio_data.unsubmitted_oe_range_start = (u64)offset;
  8689			dio_data.unsubmitted_oe_range_end = (u64)offset;
  8690			current->journal_info = &dio_data;
  8691			down_read(&BTRFS_I(inode)->dio_sem);
  8692		}
  8693	
> 8694		ret = iomap_dio_rw(iocb, iter, &btrfs_dio_iomap_ops, &btrfs_dops,
  8695				is_sync_kiocb(iocb));
  8696	
  8697		if (iov_iter_rw(iter) == WRITE) {
  8698			up_read(&BTRFS_I(inode)->dio_sem);
  8699			current->journal_info = NULL;
  8700			if (ret < 0 && ret != -EIOCBQUEUED) {
  8701				if (dio_data.reserve)
  8702					btrfs_delalloc_release_space(inode, data_reserved,
  8703						offset, dio_data.reserve, true);
  8704				/*
  8705				 * On error we might have left some ordered extents
  8706				 * without submitting corresponding bios for them, so
  8707				 * cleanup them up to avoid other tasks getting them
  8708				 * and waiting for them to complete forever.
  8709				 */
  8710				if (dio_data.unsubmitted_oe_range_start <
  8711				    dio_data.unsubmitted_oe_range_end)
  8712					__endio_write_update_ordered(inode,
  8713						dio_data.unsubmitted_oe_range_start,
  8714						dio_data.unsubmitted_oe_range_end -
  8715						dio_data.unsubmitted_oe_range_start,
  8716						false);
  8717			} else if (ret >= 0 && (size_t)ret < count)
  8718				btrfs_delalloc_release_space(inode, data_reserved,
  8719						offset, count - (size_t)ret, true);
  8720			btrfs_delalloc_release_extents(BTRFS_I(inode), count);
  8721		}
  8722	out:
  8723		if (relock)
  8724			inode_lock(inode);
  8725		extent_changeset_free(data_reserved);
  8726		return ret;
  8727	}
  8728	

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

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

  parent reply	other threads:[~2019-12-07 11:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 15:56 [PATCH 0/8 v3] btrfs direct-io using iomap Goldwyn Rodrigues
2019-12-05 15:56 ` [PATCH 1/8] fs: Export generic_file_buffered_read() Goldwyn Rodrigues
2019-12-05 15:56 ` [PATCH 2/8] iomap: add a filesystem hook for direct I/O bio submission Goldwyn Rodrigues
2019-12-05 15:56 ` [PATCH 3/8] iomap: Remove lockdep_assert_held() Goldwyn Rodrigues
2019-12-05 15:56 ` [PATCH 4/8] btrfs: Switch to iomap_dio_rw() for dio Goldwyn Rodrigues
2019-12-05 17:18   ` Johannes Thumshirn
2019-12-05 17:19     ` Christoph Hellwig
2019-12-05 17:32       ` Johannes Thumshirn
2019-12-05 17:33         ` Christoph Hellwig
2019-12-05 17:36           ` Johannes Thumshirn
2019-12-05 17:37             ` Christoph Hellwig
2019-12-05 17:37               ` Christoph Hellwig
2019-12-05 17:40                 ` Johannes Thumshirn
2019-12-05 17:44         ` Goldwyn Rodrigues
2019-12-05 22:59   ` Nikolay Borisov
2019-12-07 11:57   ` kbuild test robot [this message]
2019-12-05 15:56 ` [PATCH 5/8] fs: Remove dio_end_io() Goldwyn Rodrigues
2019-12-05 15:56 ` [PATCH 6/8] btrfs: Wait for extent bits to release page Goldwyn Rodrigues
2019-12-05 15:56 ` [PATCH 7/8] btrfs: Remove btrfs_dio_data Goldwyn Rodrigues
2019-12-05 15:56 ` [PATCH 8/8] btrfs: remove BTRFS_INODE_READDIO_NEED_LOCK Goldwyn Rodrigues
2019-12-05 22:57   ` Nikolay Borisov
2019-12-06 15:09 ` [PATCH 0/8 v3] btrfs direct-io using iomap David Sterba
2019-12-10 23:01 [PATCH 0/8 v4] " Goldwyn Rodrigues
2019-12-10 23:01 ` [PATCH 4/8] btrfs: Switch to iomap_dio_rw() for dio Goldwyn Rodrigues
2019-12-11  8:58   ` Filipe Manana
2019-12-11 10:43   ` Nikolay Borisov
2019-12-13 19:57 [PATCH 0/8 v6] btrfs direct-io using iomap Goldwyn Rodrigues
2019-12-13 19:57 ` [PATCH 4/8] btrfs: Switch to iomap_dio_rw() for dio Goldwyn Rodrigues
2019-12-21 14:42   ` Christoph Hellwig
2020-01-02 18:01     ` Goldwyn Rodrigues
2020-01-07 17:23       ` Christoph Hellwig
2020-01-07 11:59     ` Goldwyn Rodrigues
2020-01-07 17:21       ` Christoph Hellwig

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=201912071924.5kiMTl21%lkp@intel.com \
    --to=lkp@intel.com \
    --cc=kbuild-all@lists.01.org \
    /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.