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, 15 Jun 2010 13:20:38 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	Greg KH <gregkh@...e.de>, mingo@...e.hu, tglx@...utronix.de,
	bphilips@...e.de, yinghai@...nel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	jeff@...zik.org, linux-ide@...r.kernel.org,
	stern@...land.harvard.edu, khali@...ux-fr.org
Subject: Re: [PATCH 12/12] usb: use IRQ watching

Hello, Kay.

On 06/15/2010 12:30 PM, Kay Sievers wrote:
>> Hmm... maybe what we can do is generating an uevent when an IRQ is
>> confirmed to be bad and then let udev notify the user.  That way we'll
>> probably have better chance of getting bug reports and users have
>> whiny but working system.
> 
> Not really, uevents are not picked up by anything that could report an
> error to userspace, they are just seen by udev. Also uevents are
> usually not the proper passing method. They are not meant to ever
> transport higher frequency events, or structured data. They cause to
> run the entire udev rule matching machine, and update symlinks and
> permissions with every event.

Oh, these will be very low frequency event.  At most once per
irq_expect or irqaction.  e.g. on a machine with four hard drives, it
can only happen four times after boot unless the driver is unloaded
and reloaded, so from frequency standpoint it should be okay.

> We will need some better error reporting facility. On Linux you don't
> even get notified when the kernel mounts your filesystem read-only
> because of an error. It will only end up in 'dmesg' as a pretty much
> undefined bunch of words. :)

That one is a very low frequency too.

> We will need some generic error reporting facility, with structured
> data exported, and where userspace stuff can subscribe to.
> Uevents/udev can not really properly provide such infrastructure.
> Maybe that can be extended somehow, but using kobject_uevent() and
> trigger the usual udev rule engine is not what we are looking for, for
> sane error reporting.

It's true that there are higher frequency events which will be
horrible to report via kobject_uevent().  Hmmm... but the thing is
that events which should annoy the user by userland notification can't
be definition high freq.  There's only so many users can recognize and
respond, so the frequency limitation of uevent might actually fit here
although it would be nice to have some kind of safety mechanism.
Still no go for uevent?

Thanks.

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