From: kernel test robot <lkp@intel.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [RFC PATCH 3/5] sched/core: Track blocked tasks retained on rq for proxy
Date: Tue, 18 Nov 2025 04:44:24 +0800 [thread overview]
Message-ID: <202511180452.4hbbjwkB-lkp@intel.com> (raw)
In-Reply-To: <20251117185550.365156-4-kprateek.nayak@amd.com>
Hi Prateek,
[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:
[auto build test ERROR on 33cf66d88306663d16e4759e9d24766b0aaa2e17]
url: https://github.com/intel-lab-lkp/linux/commits/K-Prateek-Nayak/sched-psi-Make-psi-stubs-consistent-for-CONFIG_PSI/20251118-030832
base: 33cf66d88306663d16e4759e9d24766b0aaa2e17
patch link: https://lore.kernel.org/r/20251117185550.365156-4-kprateek.nayak%40amd.com
patch subject: [RFC PATCH 3/5] sched/core: Track blocked tasks retained on rq for proxy
config: nios2-allnoconfig (https://download.01.org/0day-ci/archive/20251118/202511180452.4hbbjwkB-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251118/202511180452.4hbbjwkB-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/202511180452.4hbbjwkB-lkp@intel.com/
All errors (new ones prefixed by >>):
kernel/sched/core.c: In function 'clear_task_proxy':
>> kernel/sched/core.c:6681:20: error: type of 'p' defaults to 'int' [-Werror=implicit-int]
6681 | static inline void clear_task_proxy(p) { }
| ^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +6681 kernel/sched/core.c
6557
6558 /*
6559 * Find runnable lock owner to proxy for mutex blocked donor
6560 *
6561 * Follow the blocked-on relation:
6562 * task->blocked_on -> mutex->owner -> task...
6563 *
6564 * Lock order:
6565 *
6566 * p->pi_lock
6567 * rq->lock
6568 * mutex->wait_lock
6569 *
6570 * Returns the task that is going to be used as execution context (the one
6571 * that is actually going to be run on cpu_of(rq)).
6572 */
6573 static struct task_struct *
6574 find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
6575 {
6576 struct task_struct *owner = NULL;
6577 int this_cpu = cpu_of(rq);
6578 struct task_struct *p;
6579 struct mutex *mutex;
6580
6581 /* Follow blocked_on chain. */
6582 for (p = donor; task_is_blocked(p); p = owner) {
6583 mutex = p->blocked_on;
6584 /* Something changed in the chain, so pick again */
6585 if (!mutex)
6586 return NULL;
6587 /*
6588 * By taking mutex->wait_lock we hold off concurrent mutex_unlock()
6589 * and ensure @owner sticks around.
6590 */
6591 guard(raw_spinlock)(&mutex->wait_lock);
6592
6593 /* Check again that p is blocked with wait_lock held */
6594 if (mutex != __get_task_blocked_on(p)) {
6595 /*
6596 * Something changed in the blocked_on chain and
6597 * we don't know if only at this level. So, let's
6598 * just bail out completely and let __schedule()
6599 * figure things out (pick_again loop).
6600 */
6601 return NULL;
6602 }
6603
6604 owner = __mutex_owner(mutex);
6605 if (!owner) {
6606 __clear_task_blocked_on(p, mutex);
6607 return p;
6608 }
6609
6610 if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) {
6611 /* XXX Don't handle blocked owners/delayed dequeue yet */
6612 return proxy_deactivate(rq, donor);
6613 }
6614
6615 if (task_cpu(owner) != this_cpu) {
6616 /* XXX Don't handle migrations yet */
6617 return proxy_deactivate(rq, donor);
6618 }
6619
6620 if (task_on_rq_migrating(owner)) {
6621 /*
6622 * One of the chain of mutex owners is currently migrating to this
6623 * CPU, but has not yet been enqueued because we are holding the
6624 * rq lock. As a simple solution, just schedule rq->idle to give
6625 * the migration a chance to complete. Much like the migrate_task
6626 * case we should end up back in find_proxy_task(), this time
6627 * hopefully with all relevant tasks already enqueued.
6628 */
6629 return proxy_resched_idle(rq);
6630 }
6631
6632 /*
6633 * Its possible to race where after we check owner->on_rq
6634 * but before we check (owner_cpu != this_cpu) that the
6635 * task on another cpu was migrated back to this cpu. In
6636 * that case it could slip by our checks. So double check
6637 * we are still on this cpu and not migrating. If we get
6638 * inconsistent results, try again.
6639 */
6640 if (!task_on_rq_queued(owner) || task_cpu(owner) != this_cpu)
6641 return NULL;
6642
6643 if (owner == p) {
6644 /*
6645 * It's possible we interleave with mutex_unlock like:
6646 *
6647 * lock(&rq->lock);
6648 * find_proxy_task()
6649 * mutex_unlock()
6650 * lock(&wait_lock);
6651 * donor(owner) = current->blocked_donor;
6652 * unlock(&wait_lock);
6653 *
6654 * wake_up_q();
6655 * ...
6656 * ttwu_runnable()
6657 * __task_rq_lock()
6658 * lock(&wait_lock);
6659 * owner == p
6660 *
6661 * Which leaves us to finish the ttwu_runnable() and make it go.
6662 *
6663 * So schedule rq->idle so that ttwu_runnable() can get the rq
6664 * lock and mark owner as running.
6665 */
6666 return proxy_resched_idle(rq);
6667 }
6668 /*
6669 * OK, now we're absolutely sure @owner is on this
6670 * rq, therefore holding @rq->lock is sufficient to
6671 * guarantee its existence, as per ttwu_remote().
6672 */
6673 }
6674
6675 WARN_ON_ONCE(owner && !owner->on_rq);
6676 return owner;
6677 }
6678 #else /* SCHED_PROXY_EXEC */
6679 bool is_proxy_task(struct task_struct *p) { return false; }
6680 static inline void set_task_proxy(struct task_struct *p) { }
> 6681 static inline void clear_task_proxy(p) { }
6682 static struct task_struct *
6683 find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
6684 {
6685 WARN_ONCE(1, "This should never be called in the !SCHED_PROXY_EXEC case\n");
6686 return donor;
6687 }
6688 #endif /* SCHED_PROXY_EXEC */
6689
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-11-17 20:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 18:55 [RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution K Prateek Nayak
2025-11-17 18:55 ` [PATCH 1/5] sched/psi: Make psi stubs consistent for !CONFIG_PSI K Prateek Nayak
2025-11-18 1:06 ` John Stultz
2025-11-20 5:59 ` Madadi Vineeth Reddy
2025-11-20 6:10 ` K Prateek Nayak
2025-11-20 6:22 ` Madadi Vineeth Reddy
2025-12-02 14:32 ` Johannes Weiner
2025-11-17 18:55 ` [PATCH 2/5] sched/psi: Prepend "0x" to format specifiers when printing PSI flags K Prateek Nayak
2025-11-18 1:08 ` John Stultz
2025-12-02 14:33 ` Johannes Weiner
2025-11-17 18:55 ` [RFC PATCH 3/5] sched/core: Track blocked tasks retained on rq for proxy K Prateek Nayak
2025-11-17 20:44 ` kernel test robot [this message]
2025-11-18 2:03 ` K Prateek Nayak
2025-11-18 1:46 ` kernel test robot
2025-11-18 4:38 ` K Prateek Nayak
2025-11-17 18:55 ` [RFC PATCH 4/5] sched/core: Block proxy task on pick when blocked_on is cleared before wakeup K Prateek Nayak
2025-11-17 18:55 ` [RFC PATCH 5/5] sched/psi: Fix PSI signals of blocked tasks retained for proxy K Prateek Nayak
2025-11-18 0:45 ` [RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution John Stultz
2025-11-18 1:38 ` K Prateek Nayak
2025-11-18 4:26 ` John Stultz
2025-11-18 5:08 ` K Prateek Nayak
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=202511180452.4hbbjwkB-lkp@intel.com \
--to=lkp@intel.com \
--cc=kprateek.nayak@amd.com \
--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.