Linux IOMMU Development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Joerg Roedel <jroedel@suse.de>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Kevin Tian <kevin.tian@intel.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Vasant Hegde <vasant.hegde@amd.com>
Subject: Re: [PATCH rc] iommu: Fix crash during syfs iommu_groups/N/type
Date: Mon, 10 Jul 2023 13:30:32 -0300	[thread overview]
Message-ID: <ZKwyKPiPIsOGAO4t@nvidia.com> (raw)
In-Reply-To: <ZKfNNT1yzDNRj-II@suse.de>

On Fri, Jul 07, 2023 at 10:30:45AM +0200, Joerg Roedel wrote:
> On Mon, Jun 26, 2023 at 12:13:11PM -0300, Jason Gunthorpe wrote:
> > The err_restore_domain flow was accidently inserted into the success path
> > in commit 1000dccd5d13 ("iommu: Allow IOMMU_RESV_DIRECT to work on
> > ARM"). It should only happen if iommu_create_device_direct_mappings()
> > fails. This caused the domains the be wrongly changed and freed whenever
> > the sysfs is used, resulting in an oops:
> > 
> >   BUG: kernel NULL pointer dereference, address: 0000000000000000
> >   #PF: supervisor read access in kernel mode
> >   #PF: error_code(0x0000) - not-present page
> >   PGD 0 P4D 0
> >   Oops: 0000 [#1] PREEMPT SMP NOPTI
> >   CPU: 1 PID: 3417 Comm: avocado Not tainted 6.4.0-rc4-next-20230602 #3
> >   Hardware name: Dell Inc. PowerEdge R6515/07PXPY, BIOS 2.3.6 07/06/2021
> >   RIP: 0010:__iommu_attach_device+0xc/0xa0
> >   Code: c0 c3 cc cc cc cc 48 89 f0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 54 55 48 8b 47 08 <48> 8b 00 48 85 c0 74 74 48 89 f5 e8 64 12 49 00 41 89 c4 85 c0 74
> >   RSP: 0018:ffffabae0220bd48 EFLAGS: 00010246
> >   RAX: 0000000000000000 RBX: ffff9ac04f70e410 RCX: 0000000000000001
> >   RDX: ffff9ac044db20c0 RSI: ffff9ac044fa50d0 RDI: ffff9ac04f70e410
> >   RBP: ffff9ac044fa50d0 R08: 1000000100209001 R09: 00000000000002dc
> >   R10: 0000000000000000 R11: 0000000000000000 R12: ffff9ac043d54700
> >   R13: ffff9ac043d54700 R14: 0000000000000001 R15: 0000000000000001
> >   FS:  00007f02e30ae000(0000) GS:ffff9afeb2440000(0000) knlGS:0000000000000000
> >   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >   CR2: 0000000000000000 CR3: 000000012afca006 CR4: 0000000000770ee0
> >   PKRU: 55555554
> >   Call Trace:
> >    <TASK>
> >    ? __die+0x24/0x70
> >    ? page_fault_oops+0x82/0x150
> >    ? __iommu_queue_command_sync+0x80/0xc0
> >    ? exc_page_fault+0x69/0x150
> >    ? asm_exc_page_fault+0x26/0x30
> >    ? __iommu_attach_device+0xc/0xa0
> >    ? __iommu_attach_device+0x1c/0xa0
> >    __iommu_device_set_domain+0x42/0x80
> >    __iommu_group_set_domain_internal+0x5d/0x160
> >    iommu_setup_default_domain+0x318/0x400
> >    iommu_group_store_type+0xb1/0x200
> >    kernfs_fop_write_iter+0x12f/0x1c0
> >    vfs_write+0x2a2/0x3b0
> >    ksys_write+0x63/0xe0
> >    do_syscall_64+0x3f/0x90
> >    entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> >   RIP: 0033:0x7f02e2f14a6f
> > 
> > Reorganize the error flow so that the success branch and error branches
> > are clearer.
> > 
> > Cc: <stable@vger.kernel.org>
> > Fixes: 1000dccd5d13 ("iommu: Allow IOMMU_RESV_DIRECT to work on ARM")
> 
> 
> Why is this Cc stable? The causing patch is not in any released kernel.

I don't keep track of when/where all the patches end up in stable. It
is now in -rc1 so it could be picked at any time. This is an important
bugfix so it should be backported if necessary.

If you know it is not in stable then please drop it when you merge it..

Otherwise it is harmless metadata, AFAIK.

Jason

  reply	other threads:[~2023-07-10 16:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26 15:13 [PATCH rc] iommu: Fix crash during syfs iommu_groups/N/type Jason Gunthorpe
2023-06-27  5:50 ` Tian, Kevin
2023-06-27  7:43 ` Baolu Lu
2023-07-07  8:30 ` Joerg Roedel
2023-07-10 16:30   ` Jason Gunthorpe [this message]
2023-07-14 12:49 ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZKwyKPiPIsOGAO4t@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dheerajkumar.srivastava@amd.com \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=kevin.tian@intel.com \
    --cc=robin.murphy@arm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox