From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sipsolutions.net (s3.sipsolutions.net [168.119.38.16]) (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 3B43A37F00A; Wed, 4 Mar 2026 06:57:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.38.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772607433; cv=none; b=oZAUFYIicn/W19dKiLNwgtuBKCt1URsd7k51GbYisyjQdDCDUcwlsWzbVyTLJlCJd1ntXl21F764Az3C3aqXCmpax97UNTZWwFu6DrqkMlOl4azc1B1M4xkUUM2nREea3qyNm/t4+o5khaFtXBtDLZpvfQSCsfFPFNt+5Ke4Mnc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772607433; c=relaxed/simple; bh=/IAZNGb8U+o1n4QhnJ3f6gmcEZ4hlQTiBODEJe2qmk4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=SXfjqz92boM8LadakHRBxeowylrCxb6nR4ofe2ktARQc7AFEcIITeCJXgtUR7yyn4GFmUYnT+do6xXQEYsUbbCIltRMwDs3pGBO5wwwqcvUIZ8uueSw+rTvWCPvhTzQ+F5qcDat+2lNrg4ONa5KueyoOGB/NtHPJB8AqJHNMzfE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sipsolutions.net; spf=pass smtp.mailfrom=sipsolutions.net; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b=mYiBJZGy; arc=none smtp.client-ip=168.119.38.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b="mYiBJZGy" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=3+EnodLK0qo4vNFhzJGniE+KK/MTe7ewq/aS9nxSw7w=; t=1772607432; x=1773817032; b=mYiBJZGy6We6Y7TT3xrUPF4FHGDUGS0behWIivtngLya6XA QV/J9AColVaAfuGHR4cPI7u/EzBjk7PJucm98HguMc0K8g2hT2j+lJyWMJ7Pjk6zJqws9VEy4yEoh +vLUcoiUj+GZaxrwDD+Kw13PIW0ftjtUwGnT9t+SDFHEM/vuTEgmQ/AqylKXjHCngwa/4ikTXKCgg 84uuaAQRDzrhiaDoxCT6S9cJwnaMfjQvN/UZtqBZxKvQBiIiHmmIwaHpPYyQUVN+EOykYlJWcnTpS 7QFwWtC4UaVBZpkCkqBpxYZC+HiV12OrAy9oE1saduXT+SwNaOg057p4u2p3cUlQ==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.98.2) (envelope-from ) id 1vxgAI-00000007vRb-0A7m; Wed, 04 Mar 2026 07:57:02 +0100 Message-ID: <4b5584f3277d667bead0b851c5bdc5cc07e80183.camel@sipsolutions.net> Subject: Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active. From: Johannes Berg To: Hillf Danton Cc: Ben Greear , linux-wireless , "Korenblit, Miriam Rachel" , linux-mm@kvack.org, Tejun Heo , linux-kernel@vger.kernel.org Date: Wed, 04 Mar 2026 07:57:01 +0100 In-Reply-To: <20260304030835.610-1-hdanton@sina.com> References: <18c4bfed-caca-bef3-a139-63d7fa48940a@candelatech.com> <3456b2c89f057900b39ce79ea8ca1154c5014e43.camel@sipsolutions.net> <0de6c8d1-d2fa-44ac-8025-cfcfecd87b02@candelatech.com> <20260304030835.610-1-hdanton@sina.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-malware-bazaar: not-scanned On Wed, 2026-03-04 at 11:08 +0800, Hillf Danton wrote: > >=20 > > Fair. I don't know, I don't think there's anything that even shows that > > there's a dependency between the two workqueues and the > > "((wq_completion)events_unbound)" and "((wq_completion)events)", and > > there would have to be for it to deadlock this way because of that? > >=20 > Given the locks held [1], >=20 > kworker/1:0/39480 kworker/u32:11/34989 > rtnl_mutex > &rdev->wiphy.mtx > __lru_add_drain_all > flush_work(&per_cpu(lru_add_drain_work, cpu)) > &rdev->wiphy.mtx >=20 > __if__ there is one work item queued __before__ one of the flush targets = on > workqueue and it acquires the rtnl mutex, then no deadlock can rise, > because worker-xyz gets off CPU due to failing to take the rtnl lock then > worker-xyz+1 dequeus the flush target and completes it due to nothing > with rtnl. Same applies to the wiphy lock. Right. > BTW any chance for queuing work that acquires rtnl lock on mm_percpu_wq? There really is only the work I was describing and vmstat_work (calling vmstat_update) on that workqueue, afaict. johannes