From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 657F72D9EDC for ; Mon, 20 Apr 2026 07:02:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776668580; cv=none; b=lE+GT59Hx6K8RV4sPD438COxn7yKm2putNyKIUe5Igr4d/XNEUxigHyEIfyFBcxRoH67oZHUEN6cVQRzUQiX8jh5ZvuZHpqykCRD2AJ2ie9fSvjMSwFdPZBINfWmn7FXCs18snaEwBVnvL8yhmllc8J088lfoLcQogHNyBPAWvM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776668580; c=relaxed/simple; bh=Zr4VYv6zq09N6d7GeoSv9myPRkhph819UYWZ6zJQGos=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iihasfCbzuHARsJ4Y6s9PFQKX8khhz7AzXo6R9Hl4tu/V8/tvTUkkO3rwK0+gspgYEF0pmJ5ImPzTsXKXYos4DBi4Z45q8acv26VsGrxDviHvwxuG/IkDP0C5A6Cu580AM/Pu9ba1cnmeE6VniT9ofVOasNSUkNYAhJoERNxh94= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OcKwoGhN; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OcKwoGhN" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-43cfde3c3f3so2979067f8f.3 for ; Mon, 20 Apr 2026 00:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776668577; x=1777273377; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=ytColbIYt3Rp0RtccuT3actoBUlgarroshZJSkhwQPc=; b=OcKwoGhNmGZj+/glkxrAi1e0qRIdQGjc/yBPnNxy5KkwdW7vZHmY9lX5fEgVLG/iwt Feu1RjguwOrvKv93RdiYrdFixFJ3+qB7iuZcnaRbNdHZyTSaWYVcBO5f9vvmpk40I6QL HzgIilGcZ/wMGjMZQsES4bdT2ArAiR2EAke0f4BNSJxzaVv5x67r6HGVgvgduifRscjQ 4OrXqYbugxlP1Y0nVI4fo1XL2mQWlgyVYwBOhfYdaFUoBTknVb0DF5wW+FkD/TXCPzND jOcnjzwq0rM12lJp8HpSeyJIUz2svW6PmMOyQ0x6PuMbtL58XqP8SKiLZpGzSGHDWv06 IsFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776668577; x=1777273377; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ytColbIYt3Rp0RtccuT3actoBUlgarroshZJSkhwQPc=; b=m1v0kwOg0CJtyKZZnFRq/RTZmGXldagMrcn/NrmjaCrYgxeDAdklwnc3Na3XbeDfN5 4pHPquD6G5PD6tCeQaVWMqZ9PJXKVNE8Jfu+94zk4AVozcGp5KEsiAmCaOZO67o38j5T ZRcrfeQ7/e4PNx/Fn2RIweGZ0+G8UkyPUpvXH7G55RAxhugV6EVPAug12eiUlE5bjTp9 fu/5rw2PRCszoPVeKLOxpJJ2XXzGA95pVrccE2kcSqGFuji0Of/Kk8KOhBkQTGcZuyCq jb3GM06oPfRXVkqoj8+x4SzISEF7u4cAZN29iNJukh7xWHKPTFYlFLsHNkmJr+xiB8Yw 9Q8g== X-Forwarded-Encrypted: i=1; AFNElJ/3gvHW1w/ZdpjqWQ5fJijQMFXBBaHej7tUqGAcI49jVnC4clt5UABTzr8T7YwXoa2vGQ9MPx60wpnVnDw=@vger.kernel.org X-Gm-Message-State: AOJu0Yxc5j6oPLBtyyieKetOs7KdOjtQ8L/YOSpq4j/BLSMsCLlXVcAj 7/zdmAHRO0xPxJEqREckuS7fKIkw4j/uHBXQmUgRDPUIin3qCHc99Xe7 X-Gm-Gg: AeBDievzA4S0Gc1ZRrd5amCDXemmjhHbv1QgR6IxEFe+ylxmJnMQz5K0jB2OVJDrb2/ /DultS6YzFIL9Sok8MKq0kSQO1OgCEByTC2KxbjzdfuLc0ipgjMslvNhPIAhX2UklppZrYh4Hs/ qVfXRMMJjz7xE/JRP80H0IKF6hZtGOVFRguBjStQ8fv1jMH11pj0QO6PLRXdiWxpafTqxmamgHA NzI6sxoVVSkrfyjL+fnkXczEoJk6te6/ipJBcstFsV4zFO93CdbQW2MmkubpZSCO8xuE4hr9Kyp wnh81qAWIK+XVkj6T9nNa+bIIjGhgGPgMz3PbtRlcc7hvL1M5SUniuW3qMdSbtu1U3JjToPDloZ sevJMSkCpY6nBsbYBYQpLyxmll3g9ctZOY5N+cPhEb+U041Rpqy/aAM2Djf6UK33MJl+zsymhTr Y+CT6ZY1OK/3lJgnHlwz3FUm/8tYhH6LFSoYYQ6KaZDJFjCPSH5Ej9H4P6X/40EgoSZprLkN4N5 XXfqFRaN8odU+h/FCA= X-Received: by 2002:a05:6000:184b:b0:43b:3d02:7806 with SMTP id ffacd0b85a97d-43fe3e0bd7fmr19154024f8f.28.1776668576308; Mon, 20 Apr 2026 00:02:56 -0700 (PDT) Received: from fedora (185-147-214-8.mad.as62651.net. [185.147.214.8]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4dc24cfsm27212311f8f.16.2026.04.20.00.02.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2026 00:02:55 -0700 (PDT) Date: Mon, 20 Apr 2026 15:02:50 +0800 From: Ming Lei To: Michael Wu Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@kernel.dk Subject: Re: [PATCH] block: fix deadlock between blk_mq_freeze_queue and blk_mq_dispatch_list Message-ID: References: <20260417082744.30124-1-michael@allwinnertech.com> <5fec2f0f-97e5-2c7a-73bd-ad2ad95f2e1d@allwinnertech.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5fec2f0f-97e5-2c7a-73bd-ad2ad95f2e1d@allwinnertech.com> On Mon, Apr 20, 2026 at 02:31:14PM +0800, Michael Wu wrote: > I'd like to add some important information: > > The three processes I mentioned—Task 1838 (Back-P10-3), Task 619 > (android.hardwar), and Task 1865 (sp-control-1)—are all in an > uninterruptible sleep state. Therefore, once Task 1865 (sp-control-1) is > scheduled out using `preempt_schedule_notrace`, it cannot be scheduled back. > The reason Task 1865 (sp-control-1) is in an uninterruptible sleep state is > because `down_write` is waiting for `io_rwsem`. > > My analysis of the upstream kernel code doesn't seem to have found a fix for > this issue. This situation should theoretically exist, but I don't have a > platform to test this low-probability behavior. However, it's certain that > this situation occurs during I/O scheduling algorithm switching and > concurrent F2FS write operations. > > In this situation, `io_schedule_prepare` is not used. The path used in Task > 1865 is `schedule->sched_submit_work->blk_flush_plug->blk_mq_dispatch_list`. > > As you said, this method is indeed not good, but I don't have a better idea > to handle this deadlock situation. Now I got the idea, because blk_flush_plug() is called on a sleeping task, that is why the preempted code block can't get run again even though it doesn't sleep anywhere. Can you try the following change? diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b7f77c165a6e..4217aaaa8e47 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6966,7 +6966,9 @@ static inline void sched_submit_work(struct task_struct *tsk) * If we are going to sleep and we have plugged IO queued, * make sure to submit it to avoid deadlocks. */ + preempt_disable_notrace(); blk_flush_plug(tsk->plug, true); + preempt_enable_no_resched_notrace(); lock_map_release(&sched_map); } thanks, Ming