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-next>] [day] [month] [year] [list]
Date:	Sat, 28 May 2011 01:04:49 +0200
From:	Arvid Brodin <arvid.brodin@...a.com>
To:	linux-kernel@...r.kernel.org
CC:	linux-usb@...r.kernel.org, Juergen Beisert <jbe@...gutronix.de>
Subject: A standardized way of reporting kernel events to userspace

Hi,

After I asked on linux-usb for a way for userspace to catch over-current events
on the usb bus, it turned out that Juergen Beisert had had the need to do the
exact same thing some time ago. He posted this patch using a uevent to notify
userspace:

Signed-off-by: Juergen Beisert <jbe@...gutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik@...gutronix.de>
---
 drivers/usb/core/hub.c           |    4 ++++
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 84c18971..c615292 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3372,9 +3372,13 @@ static void hub_events(void)
 			}
 			
 			if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
+				char event[] = "POWERFAIL=1";
+				char *envp[] = { event, NULL };
+
 				dev_err (hub_dev,
 					"over-current change on port %d\n",
 					i);
+				kobject_uevent_env(&hub->intfdev->kobj, KOBJ_CHANGE, envp);
 				clear_port_feature(hdev, i,
 					USB_PORT_FEAT_C_OVER_CURRENT);
 				hub_power_on(hub, true);


Alan Stern noted that having a standardized, accepted way for the kernel to
report important hardware or software events to userspace could be useful, and
suggested we start a discussion about this here on lkml. He noted some
things to consider:

	The type of event (hardware failure, data structure corruption,
	imminent data loss, imminent hardware destruction...).

	Whether or not the user can do anything to fix the problem.

	Whatever else you can think of.


So, please feel free to comment on this, and perhaps with time some kind of
consensus can be reached on how to report issues like this to userspace.

(My initial email to linux-usb: http://www.spinics.net/lists/linux-usb/msg47088.html)

-- 
Arvid Brodin
Enea Services Stockholm AB
--
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