All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Josef Bacik <josef@toxicpanda.com>,
	linux-btrfs@vger.kernel.org, kernel-team@fb.com
Cc: kbuild-all@lists.01.org
Subject: Re: [PATCH v3 4/5] btrfs: do not infinite loop in data reclaim if we aborted
Date: Sat, 2 Oct 2021 05:48:55 +0800	[thread overview]
Message-ID: <202110020509.wIeZvYBo-lkp@intel.com> (raw)
In-Reply-To: <03b2f64b3acc918b67c2fef6d4bfce70ab12ce3b.1632765815.git.josef@toxicpanda.com>

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

Hi Josef,

I love your patch! Yet something to improve:

[auto build test ERROR on v5.15-rc3]
[cannot apply to kdave/for-next next-20210922]
[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/Josef-Bacik/Miscellaneous-error-handling-patches/20210929-185151
base:    5816b3e6577eaa676ceb00a848f0fd65fe2adc29
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 11.2.0
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/4d626ae95cb373b954751bcdadacf6b0f92f3a6c
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Josef-Bacik/Miscellaneous-error-handling-patches/20210929-185151
        git checkout 4d626ae95cb373b954751bcdadacf6b0f92f3a6c
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross ARCH=nios2 

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

All errors (new ones prefixed by >>):

   fs/btrfs/space-info.c: In function 'maybe_fail_all_tickets':
>> fs/btrfs/space-info.c:888:30: error: implicit declaration of function 'btrfs_has_fs_error'; did you mean 'btrfs_handle_fs_error'? [-Werror=implicit-function-declaration]
     888 |         const bool aborted = btrfs_has_fs_error(fs_info);
         |                              ^~~~~~~~~~~~~~~~~~
         |                              btrfs_handle_fs_error
   cc1: all warnings being treated as errors


vim +888 fs/btrfs/space-info.c

   867	
   868	/*
   869	 * maybe_fail_all_tickets - we've exhausted our flushing, start failing tickets
   870	 * @fs_info - fs_info for this fs
   871	 * @space_info - the space info we were flushing
   872	 *
   873	 * We call this when we've exhausted our flushing ability and haven't made
   874	 * progress in satisfying tickets.  The reservation code handles tickets in
   875	 * order, so if there is a large ticket first and then smaller ones we could
   876	 * very well satisfy the smaller tickets.  This will attempt to wake up any
   877	 * tickets in the list to catch this case.
   878	 *
   879	 * This function returns true if it was able to make progress by clearing out
   880	 * other tickets, or if it stumbles across a ticket that was smaller than the
   881	 * first ticket.
   882	 */
   883	static bool maybe_fail_all_tickets(struct btrfs_fs_info *fs_info,
   884					   struct btrfs_space_info *space_info)
   885	{
   886		struct reserve_ticket *ticket;
   887		u64 tickets_id = space_info->tickets_id;
 > 888		const bool aborted = btrfs_has_fs_error(fs_info);
   889	
   890		trace_btrfs_fail_all_tickets(fs_info, space_info);
   891	
   892		if (btrfs_test_opt(fs_info, ENOSPC_DEBUG)) {
   893			btrfs_info(fs_info, "cannot satisfy tickets, dumping space info");
   894			__btrfs_dump_space_info(fs_info, space_info);
   895		}
   896	
   897		while (!list_empty(&space_info->tickets) &&
   898		       tickets_id == space_info->tickets_id) {
   899			ticket = list_first_entry(&space_info->tickets,
   900						  struct reserve_ticket, list);
   901	
   902			if (!aborted && ticket->steal &&
   903			    steal_from_global_rsv(fs_info, space_info, ticket))
   904				return true;
   905	
   906			if (!aborted && btrfs_test_opt(fs_info, ENOSPC_DEBUG))
   907				btrfs_info(fs_info, "failing ticket with %llu bytes",
   908					   ticket->bytes);
   909	
   910			remove_ticket(space_info, ticket);
   911			if (aborted)
   912				ticket->error = -EIO;
   913			else
   914				ticket->error = -ENOSPC;
   915			wake_up(&ticket->wait);
   916	
   917			/*
   918			 * We're just throwing tickets away, so more flushing may not
   919			 * trip over btrfs_try_granting_tickets, so we need to call it
   920			 * here to see if we can make progress with the next ticket in
   921			 * the list.
   922			 */
   923			if (!aborted)
   924				btrfs_try_granting_tickets(fs_info, space_info);
   925		}
   926		return (tickets_id != space_info->tickets_id);
   927	}
   928	

---
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: 60767 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 v3 4/5] btrfs: do not infinite loop in data reclaim if we aborted
Date: Sat, 02 Oct 2021 05:48:55 +0800	[thread overview]
Message-ID: <202110020509.wIeZvYBo-lkp@intel.com> (raw)
In-Reply-To: <03b2f64b3acc918b67c2fef6d4bfce70ab12ce3b.1632765815.git.josef@toxicpanda.com>

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

Hi Josef,

I love your patch! Yet something to improve:

[auto build test ERROR on v5.15-rc3]
[cannot apply to kdave/for-next next-20210922]
[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/Josef-Bacik/Miscellaneous-error-handling-patches/20210929-185151
base:    5816b3e6577eaa676ceb00a848f0fd65fe2adc29
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 11.2.0
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/4d626ae95cb373b954751bcdadacf6b0f92f3a6c
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Josef-Bacik/Miscellaneous-error-handling-patches/20210929-185151
        git checkout 4d626ae95cb373b954751bcdadacf6b0f92f3a6c
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross ARCH=nios2 

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

All errors (new ones prefixed by >>):

   fs/btrfs/space-info.c: In function 'maybe_fail_all_tickets':
>> fs/btrfs/space-info.c:888:30: error: implicit declaration of function 'btrfs_has_fs_error'; did you mean 'btrfs_handle_fs_error'? [-Werror=implicit-function-declaration]
     888 |         const bool aborted = btrfs_has_fs_error(fs_info);
         |                              ^~~~~~~~~~~~~~~~~~
         |                              btrfs_handle_fs_error
   cc1: all warnings being treated as errors


vim +888 fs/btrfs/space-info.c

   867	
   868	/*
   869	 * maybe_fail_all_tickets - we've exhausted our flushing, start failing tickets
   870	 * @fs_info - fs_info for this fs
   871	 * @space_info - the space info we were flushing
   872	 *
   873	 * We call this when we've exhausted our flushing ability and haven't made
   874	 * progress in satisfying tickets.  The reservation code handles tickets in
   875	 * order, so if there is a large ticket first and then smaller ones we could
   876	 * very well satisfy the smaller tickets.  This will attempt to wake up any
   877	 * tickets in the list to catch this case.
   878	 *
   879	 * This function returns true if it was able to make progress by clearing out
   880	 * other tickets, or if it stumbles across a ticket that was smaller than the
   881	 * first ticket.
   882	 */
   883	static bool maybe_fail_all_tickets(struct btrfs_fs_info *fs_info,
   884					   struct btrfs_space_info *space_info)
   885	{
   886		struct reserve_ticket *ticket;
   887		u64 tickets_id = space_info->tickets_id;
 > 888		const bool aborted = btrfs_has_fs_error(fs_info);
   889	
   890		trace_btrfs_fail_all_tickets(fs_info, space_info);
   891	
   892		if (btrfs_test_opt(fs_info, ENOSPC_DEBUG)) {
   893			btrfs_info(fs_info, "cannot satisfy tickets, dumping space info");
   894			__btrfs_dump_space_info(fs_info, space_info);
   895		}
   896	
   897		while (!list_empty(&space_info->tickets) &&
   898		       tickets_id == space_info->tickets_id) {
   899			ticket = list_first_entry(&space_info->tickets,
   900						  struct reserve_ticket, list);
   901	
   902			if (!aborted && ticket->steal &&
   903			    steal_from_global_rsv(fs_info, space_info, ticket))
   904				return true;
   905	
   906			if (!aborted && btrfs_test_opt(fs_info, ENOSPC_DEBUG))
   907				btrfs_info(fs_info, "failing ticket with %llu bytes",
   908					   ticket->bytes);
   909	
   910			remove_ticket(space_info, ticket);
   911			if (aborted)
   912				ticket->error = -EIO;
   913			else
   914				ticket->error = -ENOSPC;
   915			wake_up(&ticket->wait);
   916	
   917			/*
   918			 * We're just throwing tickets away, so more flushing may not
   919			 * trip over btrfs_try_granting_tickets, so we need to call it
   920			 * here to see if we can make progress with the next ticket in
   921			 * the list.
   922			 */
   923			if (!aborted)
   924				btrfs_try_granting_tickets(fs_info, space_info);
   925		}
   926		return (tickets_id != space_info->tickets_id);
   927	}
   928	

---
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: 60767 bytes --]

  parent reply	other threads:[~2021-10-01 21:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27 18:05 [PATCH v3 0/5] Miscellaneous error handling patches Josef Bacik
2021-09-27 18:05 ` [PATCH v3 1/5] btrfs: change handle_fs_error in recover_log_trees to aborts Josef Bacik
2021-09-28  5:46   ` Anand Jain
2021-09-27 18:05 ` [PATCH v3 2/5] btrfs: change error handling for btrfs_delete_*_in_log Josef Bacik
2021-09-28  9:53   ` Filipe Manana
2021-09-27 18:05 ` [PATCH v3 3/5] btrfs: add a BTRFS_FS_ERROR helper Josef Bacik
2021-09-28  7:38   ` Anand Jain
2021-09-27 18:05 ` [PATCH v3 4/5] btrfs: do not infinite loop in data reclaim if we aborted Josef Bacik
2021-09-28 10:22   ` Filipe Manana
2021-10-01 21:48   ` kernel test robot [this message]
2021-10-01 21:48     ` kernel test robot
2021-09-27 18:05 ` [PATCH v3 5/5] btrfs: fix abort logic in btrfs_replace_file_extents Josef Bacik
2021-09-28 10:07   ` Filipe Manana

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=202110020509.wIeZvYBo-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=josef@toxicpanda.com \
    --cc=kbuild-all@lists.01.org \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.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.