linux-kernel - Re: [REGRESION] Suspend hangs with 3.6-rc1 on Lenovo T60 notebook

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: <502E0D9D.8070909@redhat.com>
Date:	Fri, 17 Aug 2012 11:23:41 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Miklos Szeredi <miklos@...redi.hu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [REGRESION] Suspend hangs with 3.6-rc1 on Lenovo T60 notebook

Hi all,

On 08/16/2012 10:02 PM, Rafael J. Wysocki wrote:
> On Thursday, August 16, 2012, Alan Stern wrote:
>> On Thu, 16 Aug 2012, Miklos Szeredi wrote:
>>
>>> Yes, this appears to work.  Following patch fixes the suspend oops.
>>>
>>> Thanks,
>>> Miklos
>
> OK
>
> Miklos, can you please send that to Dave with a proper changelog and
> sign-off (please add my ACK too)?  Please make it clear that this is a
> regression fix and which commit has introduced the regression.

I think that Alan's suggest fix, as implemented by Milos is great!, but
before moving forward with this someone should audit all the other
(generic) ide code for other places using the drvdata, a simple grep
for dev_get_drvdata should show these.

<snip>

>> And now you can get rid of the useless dev_set_drvdata() call.
>
> That was in the other patch I think.

No my patch was a hack to undo the results of the commit causing
the regression in the IDE case. But Alan's approach clearly is
much better! Once we are sure drvdata is not used anywhere the
dev_set_drvdata call could be removed in the place where my
hack added a second call to it. Note that there are likely
actual ide drivers using it, without setting it themselves since
the ide core was setting it. So removing it will require even more
auditing / checking.

A 3th thing which should be audited is the generic ide code assuming
that dev->driver != NULL, this is at least true for
generic_ide_remove, where:

if (drv->remove)

Should be changed to:

if (dev->driver && drv->remove)

Following the way things are done in generic_ide_shutdown, a similar
change could be needed for generic_ide_probe(), although I guess
that may never get called with dev->driver == NULL ?

Unfortunately I'm very busy with other stuff atm, so I cannot help
here other then pointing out that such audits should be done :|

Regards,

Hans
--
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/