From: kernel test robot <lkp@intel.com>
To: Haifeng Xu <haifeng.xu@shopee.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: Re: [RFC] io_uring: fix the dead lock between io_uring and core dump
Date: Fri, 28 Feb 2025 02:24:12 +0800 [thread overview]
Message-ID: <202502280245.WT5bW0xf-lkp@intel.com> (raw)
In-Reply-To: <20250226113936.385747-1-haifeng.xu@shopee.com>
Hi Haifeng,
[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on brauner-vfs/vfs.all linus/master v6.14-rc4 next-20250227]
[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#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Haifeng-Xu/io_uring-fix-the-dead-lock-between-io_uring-and-core-dump/20250226-194045
base: tip/sched/core
patch link: https://lore.kernel.org/r/20250226113936.385747-1-haifeng.xu%40shopee.com
patch subject: [RFC] io_uring: fix the dead lock between io_uring and core dump
config: i386-buildonly-randconfig-003-20250227 (https://download.01.org/0day-ci/archive/20250228/202502280245.WT5bW0xf-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250228/202502280245.WT5bW0xf-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202502280245.WT5bW0xf-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from kernel/sched/core.c:10:
In file included from include/linux/highmem.h:8:
In file included from include/linux/cacheflush.h:5:
In file included from arch/x86/include/asm/cacheflush.h:5:
In file included from include/linux/mm.h:2224:
include/linux/vmstat.h:504:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
504 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
| ~~~~~~~~~~~~~~~~~~~~~ ^
505 | item];
| ~~~~
include/linux/vmstat.h:511:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
511 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
| ~~~~~~~~~~~~~~~~~~~~~ ^
512 | NR_VM_NUMA_EVENT_ITEMS +
| ~~~~~~~~~~~~~~~~~~~~~~
>> kernel/sched/core.c:6791:40: error: no member named 'io_uring' in 'struct task_struct'
6791 | struct io_uring_task *io_uring = tsk->io_uring;
| ~~~ ^
2 warnings and 1 error generated.
vim +6791 kernel/sched/core.c
6786
6787 static inline void sched_submit_work(struct task_struct *tsk)
6788 {
6789 static DEFINE_WAIT_OVERRIDE_MAP(sched_map, LD_WAIT_CONFIG);
6790 unsigned int task_flags;
> 6791 struct io_uring_task *io_uring = tsk->io_uring;
6792
6793 /*
6794 * Establish LD_WAIT_CONFIG context to ensure none of the code called
6795 * will use a blocking primitive -- which would lead to recursion.
6796 */
6797 lock_map_acquire_try(&sched_map);
6798
6799 task_flags = tsk->flags;
6800 /*
6801 * If a worker goes to sleep, notify and ask workqueue whether it
6802 * wants to wake up a task to maintain concurrency.
6803 */
6804 if (task_flags & PF_WQ_WORKER)
6805 wq_worker_sleeping(tsk);
6806 else if (task_flags & PF_IO_WORKER)
6807 io_wq_worker_sleeping(tsk);
6808 else if ((task_flags & PF_DUMPCORE) && io_uring) {
6809 struct io_wq *wq = io_uring->io_wq;
6810
6811 io_wq_cancel_tw_create(wq);
6812 }
6813
6814 /*
6815 * spinlock and rwlock must not flush block requests. This will
6816 * deadlock if the callback attempts to acquire a lock which is
6817 * already acquired.
6818 */
6819 SCHED_WARN_ON(current->__state & TASK_RTLOCK_WAIT);
6820
6821 /*
6822 * If we are going to sleep and we have plugged IO queued,
6823 * make sure to submit it to avoid deadlocks.
6824 */
6825 blk_flush_plug(tsk->plug, true);
6826
6827 lock_map_release(&sched_map);
6828 }
6829
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-02-27 18:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 11:39 [RFC] io_uring: fix the dead lock between io_uring and core dump Haifeng Xu
2025-02-27 13:09 ` kernel test robot
2025-02-27 18:24 ` kernel test robot [this message]
2025-02-28 9:40 ` Haifeng Xu
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=202502280245.WT5bW0xf-lkp@intel.com \
--to=lkp@intel.com \
--cc=haifeng.xu@shopee.com \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
/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.