From nobody Sat Feb 7 05:44:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8CBA27E57B for ; Mon, 5 Feb 2024 19:46:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162402; cv=none; b=ZLPl0c9k2xp8WChfgaJRUVZC458bTSVXo9UbM9Um2h5W7b12eF2g+oYXKmTnKR0hdZLQ80DGRNB8j1QVNEHdFyQZkH8G38jeFrfD0CT3P9Z+z99Xbgu2c/X5R9yvJH4GNQe4c3CSKJPt7sGRzDiYmCGEKjuNeYMJNS4KdugdvHU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162402; c=relaxed/simple; bh=Q+FFFAKX8L0wFsTUyEe+rGAUs3xDIwQRI/Gs81w7hWE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=jiev9hZJvs7ddy74GS/IiLT9hDLnwmShg1/uHKTsJd8Q1xou+VMBw2/K0/qbgarrv3wCLxr9+J2VT6dfyZMT+evqrsv5M5fAgkkoazN0tqSr+Kl1In4tU671Pb+ZZeERxYruEPAuI/m3Fvtlkkv7qNd14rfOzKVrSFtxPmW0wbU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aG5bp3gT; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aG5bp3gT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707162399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iAw8XR8UIKF5pxcWD9Lf41raO40/9bfeM2Aq6TfckS8=; b=aG5bp3gTP13nJNj3TRZHvYq1G40oNAlPzYyADdC/cv4YVwQ/yopYOssBw3Szbe5ZZ/eXRc V4jwQTpc+zbVKKd4o5pw/kzI5YGHp+6EYaFZAF/63mHnBVaHopadyy0NvOztN6npwi9fZq U/1OTYGx83T4bn/mSKyTRzjXuhfwya8= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-jbBf-C3IMaayxZIYikLHnA-1; Mon, 05 Feb 2024 14:46:36 -0500 X-MC-Unique: jbBf-C3IMaayxZIYikLHnA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E7D221C04331; Mon, 5 Feb 2024 19:46:35 +0000 (UTC) Received: from llong.com (unknown [10.22.17.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id 72F041C060B3; Mon, 5 Feb 2024 19:46:35 +0000 (UTC) From: Waiman Long To: Tejun Heo , Lai Jiangshan Cc: linux-kernel@vger.kernel.org, Juri Lelli , Cestmir Kalina , Alex Gladkov , Phil Auld , Costa Shulyupin , Waiman Long Subject: [PATCH-wq v3 1/4] workqueue: Enable unbound cpumask update on ordered workqueues Date: Mon, 5 Feb 2024 14:45:59 -0500 Message-Id: <20240205194602.871505-2-longman@redhat.com> In-Reply-To: <20240205194602.871505-1-longman@redhat.com> References: <20240205194602.871505-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 Content-Type: text/plain; charset="utf-8" Ordered workqueues does not currently follow changes made to the global unbound cpumask because per-pool workqueue changes may break the ordering guarantee. IOW, a work function in an ordered workqueue may run on an isolated CPU. This patch enables ordered workqueues to follow changes made to the global unbound cpumask by temporaily freeze the newly allocated pool_workqueue by using the new frozen flag to freeze execution of newly queued work items until the old pwq has been properly flushed. This enables ordered workqueues to follow the unbound cpumask changes like other unbound workqueues at the expense of some delay in execution of work functions during the transition period. Signed-off-by: Waiman Long Tested-by: Juri Lelli --- kernel/workqueue.c | 93 +++++++++++++++++++++++++++++++++++++++------- 1 file changed, 80 insertions(+), 13 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 68c48489eab3..9b107e8a2c15 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -255,6 +255,7 @@ struct pool_workqueue { int refcnt; /* L: reference count */ int nr_in_flight[WORK_NR_COLORS]; /* L: nr of in_flight works */ + int frozen; /* L: temporarily frozen */ =20 /* * nr_active management and WORK_STRUCT_INACTIVE: @@ -1702,6 +1703,9 @@ static bool pwq_tryinc_nr_active(struct pool_workqueu= e *pwq, bool fill) =20 lockdep_assert_held(&pool->lock); =20 + if (pwq->frozen) + return false; + if (!nna) { /* BH or per-cpu workqueue, pwq->nr_active is sufficient */ obtained =3D pwq->nr_active < READ_ONCE(wq->max_active); @@ -1782,6 +1786,21 @@ static bool pwq_activate_first_inactive(struct pool_= workqueue *pwq, bool fill) } } =20 +/** + * thaw_pwq - thaw a frozen pool_workqueue + * @pwq: pool_workqueue to be thawed + */ +static void thaw_pwq(struct pool_workqueue *pwq) +{ + unsigned long flags; + + raw_spin_lock_irqsave(&pwq->pool->lock, flags); + pwq->frozen =3D false; + if (pwq_activate_first_inactive(pwq, true)) + kick_pool(pwq->pool); + raw_spin_unlock_irqrestore(&pwq->pool->lock, flags); +} + /** * node_activate_pending_pwq - Activate a pending pwq on a wq_node_nr_acti= ve * @nna: wq_node_nr_active to activate a pending pwq for @@ -4740,6 +4759,18 @@ static void pwq_release_workfn(struct kthread_work *= work) mutex_lock(&wq->mutex); list_del_rcu(&pwq->pwqs_node); is_last =3D list_empty(&wq->pwqs); + + /* + * For ordered workqueue with a frozen dfl_pwq, thaw it now. + */ + if (!is_last && (wq->flags & __WQ_ORDERED_EXPLICIT)) { + struct pool_workqueue *dfl_pwq; + + dfl_pwq =3D rcu_access_pointer(wq->dfl_pwq); + if (dfl_pwq && dfl_pwq->frozen) + thaw_pwq(dfl_pwq); + } + mutex_unlock(&wq->mutex); } =20 @@ -4906,7 +4937,22 @@ static void apply_wqattrs_cleanup(struct apply_wqatt= rs_ctx *ctx) =20 for_each_possible_cpu(cpu) put_pwq_unlocked(ctx->pwq_tbl[cpu]); + + /* + * Acquire rcu_read_lock() before refcnt can become 0 to + * ensure that ctx->dfl_pwq won't be freed. + */ + rcu_read_lock(); put_pwq_unlocked(ctx->dfl_pwq); + if ((ctx->wq->flags & __WQ_ORDERED_EXPLICIT) && + ctx->dfl_pwq && !ctx->dfl_pwq->refcnt) { + struct pool_workqueue *dfl_pwq; + + dfl_pwq =3D rcu_access_pointer(ctx->wq->dfl_pwq); + if (dfl_pwq && dfl_pwq->frozen) + thaw_pwq(dfl_pwq); + } + rcu_read_unlock(); =20 free_workqueue_attrs(ctx->attrs); =20 @@ -4966,6 +5012,15 @@ apply_wqattrs_prepare(struct workqueue_struct *wq, cpumask_copy(new_attrs->__pod_cpumask, new_attrs->cpumask); ctx->attrs =3D new_attrs; =20 + /* + * For initialized ordered workqueues, there is only one pwq (dfl_pwq). + * Temporarily the frozen flag of ctx->dfl_pwq to freeze the execution + * of newly queued work items until execution of older work items in + * the old pwq has completed. + */ + if (!list_empty(&wq->pwqs) && (wq->flags & __WQ_ORDERED_EXPLICIT)) + ctx->dfl_pwq->frozen =3D true; + ctx->wq =3D wq; return ctx; =20 @@ -5006,13 +5061,8 @@ static int apply_workqueue_attrs_locked(struct workq= ueue_struct *wq, if (WARN_ON(!(wq->flags & WQ_UNBOUND))) return -EINVAL; =20 - /* creating multiple pwqs breaks ordering guarantee */ - if (!list_empty(&wq->pwqs)) { - if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT)) - return -EINVAL; - + if (!list_empty(&wq->pwqs) && !(wq->flags & __WQ_ORDERED_EXPLICIT)) wq->flags &=3D ~__WQ_ORDERED; - } =20 ctx =3D apply_wqattrs_prepare(wq, attrs, wq_unbound_cpumask); if (IS_ERR(ctx)) @@ -6504,11 +6554,29 @@ static int workqueue_apply_unbound_cpumask(const cp= umask_var_t unbound_cpumask) if (!(wq->flags & WQ_UNBOUND) || (wq->flags & __WQ_DESTROYING)) continue; =20 - /* creating multiple pwqs breaks ordering guarantee */ + /* + * We does not support changing cpumask of an ordered workqueue + * again before the previous cpumask change is completed. + * Sleep up to 100ms in 10ms interval to allow previous + * operation to complete and skip it if not done by then. + */ if (!list_empty(&wq->pwqs)) { - if (wq->flags & __WQ_ORDERED_EXPLICIT) - continue; - wq->flags &=3D ~__WQ_ORDERED; + struct pool_workqueue *dfl_pwq; + + dfl_pwq =3D rcu_access_pointer(wq->dfl_pwq); + if (!(wq->flags & __WQ_ORDERED_EXPLICIT)) { + wq->flags &=3D ~__WQ_ORDERED; + } else if (dfl_pwq && dfl_pwq->frozen) { + int i; + + for (i =3D 0; i < 10; i++) { + msleep(10); + if (!dfl_pwq->frozen) + break; + } + if (WARN_ON_ONCE(dfl_pwq->frozen)) + continue; + } } =20 ctx =3D apply_wqattrs_prepare(wq, wq->unbound_attrs, unbound_cpumask); @@ -7024,9 +7092,8 @@ int workqueue_sysfs_register(struct workqueue_struct = *wq) int ret; =20 /* - * Adjusting max_active or creating new pwqs by applying - * attributes breaks ordering guarantee. Disallow exposing ordered - * workqueues. + * Adjusting max_active breaks ordering guarantee. Disallow exposing + * ordered workqueues. */ if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT)) return -EINVAL; --=20 2.39.3 From nobody Sat Feb 7 05:44:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C4067CF18 for ; Mon, 5 Feb 2024 19:46:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162401; cv=none; b=dJKdlx72Q85YeRbKCT7xp/1xPzF+fbP/Zn1PAV9o0I/PInFra+7zmsMNMAHBB9bY+zB8sbSzlq3jAtx3Sp3M4EswjCVBR1BEiuGvEbYxoPYJ4nMeAN3JYchae834PMZT7O92KtLwmWJtOh6O56c0mBGlKrMEKbLXSFgqDjMGrXw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162401; c=relaxed/simple; bh=UBgB7wxdCAt+ad7SnQ4VhV8QrVhO4q6rF8Sg0R0cabs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=CSnGwhaJ9OpFeUs5+R8/FCOYSzYD6QTLz+GL1xnFaWYD19kyQTWLpsSc9oL4N3WleW3IWzCt3cZQD3sEwChX7QrtGqKrYJUCz6hBATDAhUElIeNrn+9wgBtcZwdDdPIDCXqj17HiOSsNTpU6IBI43Vhkh7OTreb0AHLFV7XEswY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UzUQ9UjJ; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UzUQ9UjJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707162398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tvk5P0YwhhGGdf9RGAqGeLDJl3BLaezVv7toWoOGyh0=; b=UzUQ9UjJp/jRWZ1FFUih7Koif3FLob+rN6wAGXWblm1rU4JPbnt3HaKE11XEsk+PlfjdFO 1JMpQVFOUs68imuQfpyNeD8W0VZqwftDZ4kGYtk10SUyF7YtnUanlTQf3f0MbNteQDKjJG 4Ak9fFX4gK/XgH9FEVyAYBp5RXZwoKk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-653-gnYI3oETNTqqcyFngXnrCg-1; Mon, 05 Feb 2024 14:46:36 -0500 X-MC-Unique: gnYI3oETNTqqcyFngXnrCg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7A5FA85A58C; Mon, 5 Feb 2024 19:46:36 +0000 (UTC) Received: from llong.com (unknown [10.22.17.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id 055931C060AF; Mon, 5 Feb 2024 19:46:35 +0000 (UTC) From: Waiman Long To: Tejun Heo , Lai Jiangshan Cc: linux-kernel@vger.kernel.org, Juri Lelli , Cestmir Kalina , Alex Gladkov , Phil Auld , Costa Shulyupin , Waiman Long Subject: [PATCH-wq v3 2/4] workqueue: Thaw frozen pwq in workqueue_apply_unbound_cpumask() Date: Mon, 5 Feb 2024 14:46:00 -0500 Message-Id: <20240205194602.871505-3-longman@redhat.com> In-Reply-To: <20240205194602.871505-1-longman@redhat.com> References: <20240205194602.871505-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 Content-Type: text/plain; charset="utf-8" workqueue_apply_unbound_cpumask() cannot proceed with an ordered workqueue if its dfl_pwq is still frozen. Just do a sleep wait for it to be thawed may not work in some cases if pwq_release_workfn() is somehow prevented from being called due to resources (e.g. wq_pool_mutex) that are held by its caller. To break the logjam, we have to actively check if the frozen dfl_pwq is ready to be thawed and call thaw_pwq() directly if so. Signed-off-by: Waiman Long Tested-by: Juri Lelli --- kernel/workqueue.c | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 9b107e8a2c15..f453f339f74a 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -6541,6 +6541,33 @@ void thaw_workqueues(void) } #endif /* CONFIG_FREEZER */ =20 +/* + * Check the given ordered workqueue to see if its non-default pwq's have + * zero reference count and if so thaw the frozen default pwq. + * + * Return: + * %true if dfl_pwq has been thawed or %false otherwise. + */ +static bool ordered_workqueue_ref_check(struct workqueue_struct *wq) +{ + struct pool_workqueue *dfl_pwq =3D rcu_access_pointer(wq->dfl_pwq); + struct pool_workqueue *pwq; + int refs =3D 0; + + if (!READ_ONCE(dfl_pwq->frozen)) + return true; + mutex_lock(&wq->mutex); + for_each_pwq(pwq, wq) { + if (pwq =3D=3D dfl_pwq) + continue; + refs +=3D pwq->refcnt; + } + if (!refs) + thaw_pwq(dfl_pwq); + mutex_unlock(&wq->mutex); + return !refs; +} + static int workqueue_apply_unbound_cpumask(const cpumask_var_t unbound_cpu= mask) { LIST_HEAD(ctxs); @@ -6566,12 +6593,12 @@ static int workqueue_apply_unbound_cpumask(const cp= umask_var_t unbound_cpumask) dfl_pwq =3D rcu_access_pointer(wq->dfl_pwq); if (!(wq->flags & __WQ_ORDERED_EXPLICIT)) { wq->flags &=3D ~__WQ_ORDERED; - } else if (dfl_pwq && dfl_pwq->frozen) { + } else if (dfl_pwq && !ordered_workqueue_ref_check(wq)) { int i; =20 for (i =3D 0; i < 10; i++) { msleep(10); - if (!dfl_pwq->frozen) + if (ordered_workqueue_ref_check(wq)) break; } if (WARN_ON_ONCE(dfl_pwq->frozen)) --=20 2.39.3 From nobody Sat Feb 7 05:44:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 620DC7E59B for ; Mon, 5 Feb 2024 19:46:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162402; cv=none; b=Od2Q6AD/jsbh0OVZpx2Tc8Rn+cygnYgq/dq2CJD8uvaPGk+ZgdUA9mUrBoXrVaWGkgoWxiFXti2DNQfLMXL7jEtRGwfKjTSA5JjSUNV4zEKGvXDefYbv0R6ugmBgB93ygrKeX0v6tXFOCzmBPKVSEwdfjhvNbBO4qMU9+q+P3Fo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162402; c=relaxed/simple; bh=dD7RzPOu/yZs0SQ7pUw18W4NFsgZFjiCRghDj6nC4Pk=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ZHyQXIoexvJzzEXyhzFlNV9K6e6L6r1Ald4eZ9Fue8oa51zWBMCWtnw4eexKX32xhOw+jQX3MECywiisK92tT2Js7ZheabnstwDMzRDlKjA6XqY+7dO9+i3HRrUq/tQss+ZUZhP9PaGfO08m2f50mCRiFqw6dFXmGumCJ5Whd7g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=GHUUy+oJ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GHUUy+oJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707162400; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8fhJVNF3lWvjfwTgTO/+j3df6cdCJ3ZEvdWETu+5JAU=; b=GHUUy+oJzpVvJkdtmEBhVKo5K9wTZ/vyOJcyg/7qM7cxZspnmrUgVbJVnaFmJBe/Z3wsA/ yd+NXfwydhTOE45pqCRRKx2gEpAXPtZd9UtmGy5t4IvlWGVJFNN+QBPtKp9uKo7X4gPIWG YhFOLxBx9MHndm916dnJNPkCETiWwkI= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-584-9WDAA6SHPl2JC0toqD9PkQ-1; Mon, 05 Feb 2024 14:46:37 -0500 X-MC-Unique: 9WDAA6SHPl2JC0toqD9PkQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 096A5380451D; Mon, 5 Feb 2024 19:46:37 +0000 (UTC) Received: from llong.com (unknown [10.22.17.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id 884B51C060AF; Mon, 5 Feb 2024 19:46:36 +0000 (UTC) From: Waiman Long To: Tejun Heo , Lai Jiangshan Cc: linux-kernel@vger.kernel.org, Juri Lelli , Cestmir Kalina , Alex Gladkov , Phil Auld , Costa Shulyupin , Waiman Long Subject: [PATCH-wq v3 3/4] kernel/workqueue: Let rescuers follow unbound wq cpumask changes Date: Mon, 5 Feb 2024 14:46:01 -0500 Message-Id: <20240205194602.871505-4-longman@redhat.com> In-Reply-To: <20240205194602.871505-1-longman@redhat.com> References: <20240205194602.871505-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 Content-Type: text/plain; charset="utf-8" From: Juri Lelli When workqueue cpumask changes are committed the associated rescuer (if one exists) affinity is not touched and this might be a problem down the line for isolated setups. Make sure rescuers affinity is updated every time a workqueue cpumask changes, so that rescuers can't break isolation. [longman: set_cpus_allowed_ptr() will block until the designated task is enqueued on an allowed CPU, no wake_up_process() needed. Also use the unbound_effective_cpumask() helper as suggested by Tejun.] Signed-off-by: Juri Lelli Signed-off-by: Waiman Long Tested-by: Juri Lelli --- kernel/workqueue.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index f453f339f74a..bbd4269d2729 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -5049,6 +5049,11 @@ static void apply_wqattrs_commit(struct apply_wqattr= s_ctx *ctx) /* update node_nr_active->max */ wq_update_node_max_active(ctx->wq, -1); =20 + /* rescuer needs to respect wq cpumask changes */ + if (ctx->wq->rescuer) + set_cpus_allowed_ptr(ctx->wq->rescuer->task, + unbound_effective_cpumask(ctx->wq)); + mutex_unlock(&ctx->wq->mutex); } =20 --=20 2.39.3 From nobody Sat Feb 7 05:44:19 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8CBD57E57D for ; Mon, 5 Feb 2024 19:46:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162402; cv=none; b=TBxKrwp2UOVOd4bzRs0MydtjHYzvpp2oO9dZN66ewSb14u6Th15qENwET5whd+fgteyjTuTsHzo9i9P+hmwi/k8AgW3XJaGORWRZeUVDF5POoHz2h6D8H3jypTc+g03rpwgfrxJrHCEAbx+rCaMEyhZAv7hXTY6v9OT4IejFgoY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707162402; c=relaxed/simple; bh=vO8HGkvtn6jz0wtvFkjiJ9lBXoPwD9WE/SfztzX7xQA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=p1mVovRGlARd1WtqrrrGxgHZ6uXydrE56qQRea0pMtqbky/4h6nQWqPC78O3hZzMvmYvL9gVfjqSJXBjb6SObYNxfxMyFQxRArUsNCOW6QwQZdeZ3V6lvmFtE5ER09edKmNWJ3M195DdVOPX/HIRDOpzTZsgf4hl5v8DlDL4rYQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=NA0p9ykt; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NA0p9ykt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707162399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rbQHwYA7ykmolC0A4lTROkm5bxARusbIFHiZqSIfIjU=; b=NA0p9yktrk3mGQv45D1kuRcPMLTYOIsjsUEdC6f5b+QOBxUvP2F9AMt3PNfDlr1cp5iKpS 3ULSwxi3rexljLd+/0No7RNduN+L6RE1SlYXe6QsY6OmJFY4n6Pz5wkDuNpFJDJuB8Gnb4 j1I4FZlf5jdQ0g4dkUUO0PQ4XZRTE0I= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-5-kVMk7NwuMUSN5LxNo7eC6w-1; Mon, 05 Feb 2024 14:46:37 -0500 X-MC-Unique: kVMk7NwuMUSN5LxNo7eC6w-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8EF9785A597; Mon, 5 Feb 2024 19:46:37 +0000 (UTC) Received: from llong.com (unknown [10.22.17.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id 19E3E1C060B3; Mon, 5 Feb 2024 19:46:37 +0000 (UTC) From: Waiman Long To: Tejun Heo , Lai Jiangshan Cc: linux-kernel@vger.kernel.org, Juri Lelli , Cestmir Kalina , Alex Gladkov , Phil Auld , Costa Shulyupin , Waiman Long Subject: [PATCH-wq v3 4/4] workqueue: Bind unbound workqueue rescuer to wq_unbound_cpumask Date: Mon, 5 Feb 2024 14:46:02 -0500 Message-Id: <20240205194602.871505-5-longman@redhat.com> In-Reply-To: <20240205194602.871505-1-longman@redhat.com> References: <20240205194602.871505-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 Content-Type: text/plain; charset="utf-8" Commit 85f0ab43f9de ("kernel/workqueue: Bind rescuer to unbound cpumask for WQ_UNBOUND") modified init_rescuer() to bind rescuer of an unbound workqueue to the cpumask in wq->unbound_attrs. However unbound_attrs->cpumask's of all workqueues are initialized to cpu_possible_mask and will only be changed if it has the WQ_SYSFS flag to expose a cpumask sysfs file to be written by users. So this patch doesn't achieve what it is intended to do. If an unbound workqueue is created after wq_unbound_cpumask is modified and there is no more unbound cpumask update after that, the unbound rescuer will be bound to all CPUs unless the workqueue is created with the WQ_SYSFS flag and an user explicitly modified its cpumask sysfs file. Fix this problem by binding directly to wq_unbound_cpumask in init_rescuer(). Fixes: 85f0ab43f9de ("kernel/workqueue: Bind rescuer to unbound cpumask for= WQ_UNBOUND") Signed-off-by: Waiman Long Tested-by: Juri Lelli --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index bbd4269d2729..6077d5d663c3 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -5300,7 +5300,7 @@ static int init_rescuer(struct workqueue_struct *wq) =20 wq->rescuer =3D rescuer; if (wq->flags & WQ_UNBOUND) - kthread_bind_mask(rescuer->task, wq->unbound_attrs->cpumask); + kthread_bind_mask(rescuer->task, wq_unbound_cpumask); else kthread_bind_mask(rescuer->task, cpu_possible_mask); wake_up_process(rescuer->task); --=20 2.39.3