Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751374AbdFAG6I (ORCPT ); Thu, 1 Jun 2017 02:58:08 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58472 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751047AbdFAG6G (ORCPT ); Thu, 1 Jun 2017 02:58:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A7EBC60714 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=asutoshd@codeaurora.org To: linux-scsi@vger.kernel.org Cc: "linux-arm-msm@vger.kernel.org; linux-kernel@vger.kernel.org; subhashj"@codeaurora.org From: "Asutosh Das (asd)" Subject: [ufs]: [scsi]: BUG: spinlock recursion on CPU#4 Message-ID: Date: Thu, 1 Jun 2017 12:28:02 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2188 Lines: 75 Hi All, Recently, I came across an issue with the below call stack. -000|arch_counter_get_cntvct(inline) -000|__delay() -001|__const_udelay(?) -002|msm_trigger_wdog_bite() -003|spin_dump(inline) -003|spin_bug(lock = ?, ?) -004|current_thread_info(inline) -004|debug_spin_lock_before(inline) -004|do_raw_spin_lock() -005|raw_spin_lock_irqsave(lock = ?) -006|blk_end_bidi_request(inline) -006|blk_end_request_all(rq = ?, error = 0) <-- this tries to acquire the lock acquired by blk_delay_work (-024) and spinbug recursion occurs -007|dm_end_request(clone = ?, error = 0) -008|dm_done(inline) -008|dm_softirq_done() -009|blk_done_softirq() -010|__read_once_size(inline) -010|static_key_count(inline) -010|static_key_false(inline) -010|trace_softirq_exit(inline) -010|__do_softirq() -011|do_softirq_own_stack(inline) -011|invoke_softirq(inline) <-- softirq is triggered because scsi_request_fn (-016) enabled interrupts on this cpu -011|irq_exit() -012|handle_IPI() -013|gic_handle_irq() -014|el1_irq(asm) -->|exception -015|__raw_spin_unlock_irq(inline) -015|raw_spin_unlock_irq(lock = ?) -016|scsi_request_fn() <-- Unlocks the queue using spin_unlock, doesn't restore the flags, thus enabling the interrupts -017|__blk_run_queue_uncond(inline) -017|__blk_run_queue(q = ?) -018|__elv_add_request() -019|blk_insert_cloned_request() <-- acquires the queue lock & saves the flags -020|dm_dispatch_clone_request(clone = ?, rq = ?) -021|map_request() -022|dm_request_fn() -023|__blk_run_queue_uncond(inline) -023|__blk_run_queue -024|spin_unlock_irq(inline) -024|blk_delay_work(?) <-- also acquires a queue lock, but this is a different queue, blk_end_request_all will reference this queue -025|__read_once_size(inline) -025|static_key_count(inline) -025|static_key_false(inline) -025|trace_workqueue_execute_end(inline) -025|process_one_work() -026|worker_thread() -027|kthread() -028|ret_from_fork(asm) ---|end of frame Please can you check if this is actually a bug and my understanding is correct. If so, I can put up a patch for the same. -- Asutosh Das (asd) Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project