linux-kernel - Re: [PATCH] usb: avoid PM error messages during resume if a device was disconnected

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]

Date:	Tue, 24 Mar 2009 10:11:57 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Frans Pop <elendil@...net.nl>
cc:	linux-usb@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	<linux-pm@...ts.linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: avoid PM error messages during resume if a device
 was disconnected

On Mon, 23 Mar 2009, Frans Pop wrote:

> > Or do you think maybe it would be better to move this test up into the
> > PM core?  After all, other subsystems will face the same issue.  I
> > think that would be the best approach.  Yes?
> 
> I did look at that option, but implementing it in the USB subsystem seemed
> more logical to me, for example as other subsystems possibly would want to
> display an info message.

They still can...

> And is -ENODEV safe to ignore in all cases? Would there be other errors that
> should be ignored too?

In general, the PM core ignores _all_ errors during resume -- in the
sense that it doesn't try to recover from them or do anything to handle
them.  All it does is put a message in the log.

So your question becomes: For which errors should a message be added to 
the system log?  The most logical answer seems to be that we want an 
error message whenever something bad or unexpected occurs.

Removal of a hot-unpluggable device isn't really bad or unexpected.  
Removal of a non-hot-unpluggable device might be bad, but on the other
hand the system isn't really "hot" while it is suspended.  Besides, the
appropriate subsystem can print an error message.  Furthermore the
kernel can't easily tell which devices are hot-unpluggable and which
aren't.

Anything else amounts to failure resuming a device that still exists.  
As such, it probably deserves an error message.

> if Rafael would be happy with a generic test for -ENODEV, it could be done.
> If not, maybe some other special error code would need to be used but then
> you'd still need to test in the subsystem to set that error.
> Disadvantage is also that it would make resume_device() and related PM
> driver core functions quite a bit less clean than they currently are.
> 
> Implementing the test in USB was quite a bit simpler (for me at least ;-)

We should get Rafael's opinion.

Alan Stern

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