lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 28 Mar 2008 14:50:38 +0100
From:	Pavel Machek <pavel@....cz>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	kernel list <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: iommu breaks usb after resume

Hi!

> > > > diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
> > > > index d8200ac..4e85178 100644
> > > > --- a/drivers/char/agp/amd64-agp.c
> > > > +++ b/drivers/char/agp/amd64-agp.c
> > > > @@ -594,12 +594,14 @@ static int agp_amd64_suspend(struct pci_
> > > >  
> > > >  static int agp_amd64_resume(struct pci_dev *pdev)
> > > >  {
> > > > +	printk("agp_amd64: resume\n");
> > > >  	pci_set_power_state(pdev, PCI_D0);
> > > >  	pci_restore_state(pdev);
> > > >  
> > > >  	if (pdev->vendor == PCI_VENDOR_ID_NVIDIA)
> > > >  		nforce3_agp_init(pdev);
> > > >  
> > > > +	printk("agp_amd64: 8151 configure\n");
> > > >  	return amd_8151_configure();
> > > >  }
> > > >  
> > > > @@ -733,8 +735,8 @@ static struct pci_driver agp_amd64_pci_d
> > > >  	.probe		= agp_amd64_probe,
> > > >  	.remove		= agp_amd64_remove,
> > > >  #ifdef CONFIG_PM
> > > > -	.suspend	= agp_amd64_suspend,
> > > > -	.resume		= agp_amd64_resume,
> > > > +	.suspend_late	= agp_amd64_suspend,
> > > > +	.resume_early	= agp_amd64_resume,
> > > >  #endif
> > > >  };
> > > 
> > > Okay, a couple of questions:
> > > 
> > > (1) Are you sure that the .suspend() and .resume() callbacks will just work
> > >     with interrupts disabled?
> > 
> > I have not really checked -- it turned out this is not "my" problem
> > after all. My machine (called leet) uses different setup. If they will
> > not, I guess lockdep will tell us ;-).
> 
> Lockdep need not tell us about it, I think.  OTOH, I don't really see a
> scenario in which having interrupts disabled while executing ->suspend() and
> ->resume() might hurt.

Ok.

> > > (2) Even if they work, is it sufficient to just move them to the "late" and
> > >     "early" parts?  That is, isn't there anything using the iommu in the
> > >     "early" and "late" callbacks of the other devices?
> > 
> > We definitely have iommu users in "normal" callbacks: USB.
> 
> Oh, there may be more.  You never know what appears in future systems. :-)

Well, we'll catch them during code review, right?

> > I do not think we have iommu users in early/late callbacks...
> 
> Perhaps not at the moment, but what's the guarantee there won't be any in the
> future?

That's why we review changes... ok, maybe documenting it somewhere
would be nice...?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ