linux-kernel - Re: [Bug #13663] suspend to ram regression (IDE related)

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200907011821.26091.bzolnier@gmail.com>
Date:	Wed, 1 Jul 2009 18:21:25 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	wuzhangjin@...il.com
Cc:	Jeff Chua <jeff.chua.linux@...il.com>,
	Etienne Basset <etienne.basset@...ericable.fr>,
	David Miller <davem@...emloft.net>, rjw@...k.pl,
	linux-kernel@...r.kernel.org, kernel-testers@...r.kernel.org,
	Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...ux-mips.org,
	linux-ide@...r.kernel.org
Subject: Re: [Bug #13663] suspend to ram regression (IDE related)

On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@...il.com> wrote:
> > 
> > > I just tried, and it "seems" to work. Will try a few more cycles.
> > 
> > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > right thing.
> > 
> > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > Basset<etienne.basset@...ericable.fr> wrote:
> > 
> > > To have STR/resume work with current git, I have to :
> > 
> > > 1) apply Bart's patch
> > 
> > This is not yet in Linus's tree. And much needed to really fix the problem.
> > 
> > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > 
> 
> Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> work either. I have tested it on two different loongson-based machines:
> fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)

Since it seems like Dave is taking his sweet time with doing the revert
I stared at the code a bit more and I think that I finally found the bug
(thanks to your debugging work for giving me the right hint!).

The patch needs to take into the account a new code introduced by the recent
block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):

@@ -555,8 +560,11 @@ repeat:
                startstop = start_request(drive, rq);
                spin_lock_irq(&hwif->lock);
 
-               if (startstop == ide_stopped)
+               if (startstop == ide_stopped) {
+                       rq = hwif->rq;
+                       hwif->rq = NULL;
                        goto repeat;
+               }
        } else
                goto plug_device;
 out:

and not zero hwif->rq if the device is blocked. 

Could you try the attached patch and see if it fixes the issue?

[ Dave: while I appreciate fast handling of my patches I had strongly
  suggested giving this particular one some extra testing (because there
  were a lot of changes in between the time that it has been tested
  against other kernel subsystems).  Yet, it seems that its linux-next
  exposure was minimal at best..  :( ]

---
 drivers/ide/ide-io.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -532,7 +532,8 @@ repeat:
 
 		if (startstop == ide_stopped) {
 			rq = hwif->rq;
-			hwif->rq = NULL;
+			if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
+				hwif->rq = NULL;
 			goto repeat;
 		}
 	} else
--
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/