Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp2508868rwb; Mon, 15 Aug 2022 06:44:15 -0700 (PDT) X-Google-Smtp-Source: AA6agR6sqksTPbmGoFf9x1qexNVBVYfSG62kVdCQPRXXW6M33yHiQFSMrVNC7k4OkPCxXLD6isy2 X-Received: by 2002:a05:6402:5107:b0:43d:6b26:bdc5 with SMTP id m7-20020a056402510700b0043d6b26bdc5mr14652016edd.156.1660571055245; Mon, 15 Aug 2022 06:44:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660571055; cv=none; d=google.com; s=arc-20160816; b=Kc1IoFD3RhrhI9H9OGs+BsmV26mE5FRRQWPOcCKP1Gh5fzAonJdVDQKo7AqNS2Vd6N sTEhVc5P5F9++frg2mD0svF7R9oGpyEicirVrlehunF/C/J4+zIKlQEew8X8VMagwBId g1q3u9Aoj/uLI9DMyOIV+4nDhmAnLy+rK6kDMl1BVVob2u+YbOJF9siQkNk9zlFNIJ56 aqdDAClGfFS+XHGjKSTplOf6zdJb35D+KXKVH5i5V42gqFJui4qPPUCpVVf++elFs37Y 7c9budk4FQs+FIzqJNIyR8lQKTJCbl7DyAcFwRCJ4Z++Bci9vokwLQBx9bF60mPZRwgU 9WpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=6+NKr8x81snqBPCrj5grt+MbWltUZu5PmZe6P/3T6aM=; b=ybs1QDSb+gkUqo7wqoKT405FPLwYdXNRZdZHEdHzNcPfSzF/moiYYT71V43cbt7Aa/ oakEqOIk+Jr0xr9cR+GelMMyr5vollvCQBckkeEpMUoq0ENYEX4qWg1XRFPCy9R3vmYz yVvzgecnYHNsDOcPgvbNIvAIT78w2XehVLi5mtMu5FyA6DwA1RydycgndakSCsvvFbEo /z3OIXBA1osJ2Srun3owc7IjrnghNuOU8iJfhDOL+RvohdfU/A/BgiAcrJMGVmv1Rqrr OruLTrg5rAlBDU7QEF8zGiirpGkrcIaBNOifQGMCUy1za8LdTl8h8kfnHvRL4QmmgPE0 ADkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=acm.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id di9-20020a170906730900b007308200cc45si10608336ejc.35.2022.08.15.06.43.50; Mon, 15 Aug 2022 06:44:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=acm.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242205AbiHONcs (ORCPT + 99 others); Mon, 15 Aug 2022 09:32:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229752AbiHONca (ORCPT ); Mon, 15 Aug 2022 09:32:30 -0400 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AE5D15718 for ; Mon, 15 Aug 2022 06:32:29 -0700 (PDT) Received: by mail-pg1-f179.google.com with SMTP id v4so2163316pgi.10 for ; Mon, 15 Aug 2022 06:32:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=6+NKr8x81snqBPCrj5grt+MbWltUZu5PmZe6P/3T6aM=; b=Eul1FE/WL+1pSC4oKQfwt0TaAzuyWzUDhfnkAN+OA90ZE/aJ2hEj1YpVFWr8Tq5qY2 hJLegOObGkmNUJ58dBxBfyqa8+kJY1nuTAbLSRwecjajL/W3XAb02jzbnEoNHlZ9FcFQ 2k5bnhaQsmuAjOVmjPz1QHj8Nd5xZVq1zW8SIuddsvYmKGKAbfun7wxJIFZ5Q2EE0CMO 9mbsuf/Se0atpkQMB2OCOO2nEfhMjL7NF6dP59uZXDzSfGtf3fWL/kkoukUQiUH1mbH1 qoV/T1gsskmIisHJCE/CKz4Opi6xwthdFa+zVfdlugWjMjap44hitMoF2yesNmmlnW76 zCLQ== X-Gm-Message-State: ACgBeo2caYNjgVopazMY8Kvr6UO7xuyJJSmGJFq7lK7tkSUoIe7V/dsE N/h1IL6lLos04USNPK0SRoM= X-Received: by 2002:aa7:85da:0:b0:52f:c5bc:cb41 with SMTP id z26-20020aa785da000000b0052fc5bccb41mr16401699pfn.31.1660570348933; Mon, 15 Aug 2022 06:32:28 -0700 (PDT) Received: from [192.168.3.217] ([98.51.102.78]) by smtp.gmail.com with ESMTPSA id q5-20020a170902eb8500b0016dbe5f5308sm6916750plg.79.2022.08.15.06.32.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Aug 2022 06:32:27 -0700 (PDT) Message-ID: Date: Mon, 15 Aug 2022 06:32:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: lockdep splat due to klist iteration from atomic context in Intel IOMMU driver Content-Language: en-US To: Lennert Buytenhek , Sasha Levin , Lu Baolu , David Woodhouse , Joerg Roedel , iommu@lists.linux.dev Cc: Will Deacon , Robin Murphy , Kevin Tian , Ashok Raj , Christoph Hellwig , Jason Gunthorpe , Liu Yi L , Jacob jun Pan , linux-kernel@vger.kernel.org, Scarlett Gourley , James Sewart , Jack O'Sullivan References: From: Bart Van Assche In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/15/22 05:05, Lennert Buytenhek wrote: > On a build of 7ebfc85e2cd7 ("Merge tag 'net-6.0-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net"), with > CONFIG_INTEL_IOMMU_DEBUGFS enabled, I am seeing the lockdep splat > below when an I/O page fault occurs on a machine with an Intel > IOMMU in it. > > The issue seems to be the klist iterator functions using > spin_*lock_irq*() but the klist insertion functions using > spin_*lock(), combined with the Intel DMAR IOMMU driver iterating > over klists from atomic (hardirq) context as of commit 8ac0b64b9735 > ("iommu/vt-d: Use pci_get_domain_bus_and_slot() in pgtable_walk()") > when CONFIG_INTEL_IOMMU_DEBUGFS is enabled, where > pci_get_domain_bus_and_slot() calls into bus_find_device() which > iterates over klists. > > I found this commit from 2018: > > commit 624fa7790f80575a4ec28fbdb2034097dc18d051 > Author: Bart Van Assche > Date: Fri Jun 22 14:54:49 2018 -0700 > > scsi: klist: Make it safe to use klists in atomic context > > This commit switched lib/klist.c:klist_{prev,next} from > spin_{,un}lock() to spin_{lock_irqsave,unlock_irqrestore}(), but left > the spin_{,un}lock() calls in add_{head,tail}() untouched. > > The simplest fix for this would be to switch lib/klist.c:add_{head,tail}() > over to use the IRQ-safe spinlock variants as well? Another possibility would be to evaluate whether it is safe to revert commit 624fa7790f80 ("scsi: klist: Make it safe to use klists in atomic context"). That commit is no longer needed by the SRP transport driver since the legacy block layer has been removed from the kernel. Thanks, Bart.