From mboxrd@z Thu Jan 1 00:00:00 1970 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 92C784BD794 for ; Wed, 14 Oct 2026 12:01:38 +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=1791979299; cv=none; b=Y6qJF1VQuQp4jNCVfS81hFAPAsTfOqoBeg6FBKU9kQsEL5U/+rWOlqP27D0xYUXkSkkRI5g1ikU2cpuE7UjA77w/UibkqbToD4D7cvvzPvlOuMqqd0QPJ5N/xgJgam+P9rUg6qtd2t6R8jkZX4JJZmIWhmlVtUHFcbsBYJ/9x/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791979299; c=relaxed/simple; bh=Zwn256Ky/WnnhO/fkv1WyvwNXZkV0GXvgW7t9VZ79nY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pgJ/0KYN0/7wkJXkatOcRQy0bpjSc106i8ep8cLKzzkaPxeoY1qWNYnA5/SvUvoaCM43NduXlnrCRs3Mvekp+OY3QArjGdT+7TTW7FVyBA+0Fhl5cV/mK42vF0kiXehhhAijnBwiDg98tK/B2nVWl4wW/EVpp1O8PlLkE7tbj7Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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=hAOmadLs; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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="hAOmadLs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1791979297; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Zwn256Ky/WnnhO/fkv1WyvwNXZkV0GXvgW7t9VZ79nY=; b=hAOmadLsuQps2Uye1fkcuPvVM/D6sTYUqYQKEKSF4/IrufPRb0mGP9K0eS3907AnYhU3MP ypiYwnGDx3Z1oKc2l4EmsXllDwac7Q/jJdVxF6UUhK+qdgw6zevPk7wAdQfKTxXZ5BxNSi vgsqN+rEpElu4b5EDW+skorXP2vQcwY= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-646-9hsYaD-GMH6E9s7OscVXwQ-1; Wed, 14 Oct 2026 12:01:31 +0000 X-MC-Unique: 9hsYaD-GMH6E9s7OscVXwQ-1 X-Mimecast-MFC-AGG-ID: 9hsYaD-GMH6E9s7OscVXwQ_1791979289 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (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 mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8C6A61955F14; Wed, 14 Oct 2026 12:01:28 +0000 (UTC) Received: from onestero-thinkpadp1gen7.tpbc.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with SMTP id 83756362; Wed, 14 Oct 2026 12:01:24 +0000 (UTC) Received: by onestero-thinkpadp1gen7.tpbc.csb (nbSMTP-1.00) for uid 13628 oleg@redhat.com; Wed, 14 Oct 2026 14:01:28 +0200 (CEST) Date: Wed, 14 Oct 2026 14:01:23 +0200 From: Oleg Nesterov To: Mingyu Wang <25181214217@stu.xidian.edu.cn> Cc: w15303746062@163.com, David Laight , jlayton@kernel.org, chuck.lever@oracle.com, viro@zeniv.linux.org.uk, brauner@kernel.org, alex.aring@gmail.com, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling Message-ID: References: <20260523135210.590928-1-w15303746062@163.com> <437297ff-1bb4-49a7-a979-abccdd1814f8@stu.xidian.edu.cn> <94ee706b-f7b7-4d7c-b094-a6fc9b9174b4@stu.xidian.edu.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94ee706b-f7b7-4d7c-b094-a6fc9b9174b4@stu.xidian.edu.cn> X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 On 10/13, Mingyu Wang wrote: > > Hi Oleg, > > In the scenario you described, the tasklist_lock reader holding > dev->event_lock is in process context. That explains why the > interrupt-reader handling does not rule out the possible deadlock. > > > > perhaps it is time to add pid->tasks_lock or abuse pid->lock we already > > have (we would need to make it irq-safe) but this doesn't look nice... > > A fix also needs to preserve the synchronization required for process > group traversal. Yes sure. send_sigio() (and other users of do_each_pid_xxx) should take the new lock instead of tasklist. OTOH. It would be really nice to not send signals from irq. This will probably allow to take signal->siglock without disabling irqs. Same for write_lock(tasklist). So _perhaps_ it makes sense to change send_sigio() to offload the actual work to workqueues. But this is the more distant goal, we need something simple for stable. I am a bit busy right now, will send the patch in a couple of days. Oleg.