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: <CACVXFVOfXBT9jPRq=WwasN0rNeaZ_T3ceZ1hsnP_QYdXHh+nDQ@mail.gmail.com>
Date:	Wed, 14 Sep 2011 09:17:03 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	rjw@...k.pl, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] PM/runtime: handle ->runtime_suspend failure correctly

Hi,

On Mon, Sep 12, 2011 at 4:44 AM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Sat, 10 Sep 2011 tom.leiming@...il.com wrote:
>
>> From: Ming Lei <tom.leiming@...il.com>
>>
>> If ->runtime_suspend returns -EAGAIN or -EBUSY, the device should
>> still be in ACTIVE state, so it is not needed to handle defered
>> resume and idle notification to its parent; if ->runtime_suspend
>> returns other fatal failure, it doesn't make sense to process defered
>> resume and send idle notification to its parent.
>
>> @@ -422,6 +425,9 @@ static int rpm_suspend(struct device *dev, int rpmflags)
>>       }
>>       wake_up_all(&dev->power.wait_queue);
>>
>> +     if (retval)
>> +             goto out;
>> +
>>       if (dev->power.deferred_resume) {
>>               rpm_resume(dev, 0);
>>               retval = -EAGAIN;
>
> If there's a suspend failure, the deferred_resume flag gets turned off
> anyway.  But skipping this test won't hurt, and skipping the parent
> notification is a good idea.

Yes, I will update the commit log.

>
> In fact, it might be even better to put a copy of the wake_up_all() in
> the "if (retval)" branch after the suspend callback and then go
> directly to out.  The "else" branch could then become part of the
> straight-through code, not indented.

Good idea, will update this in -v1.

thanks,
-- 
Ming Lei
--
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