linux-kernel - Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure

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: <BANLkTi=BsGjgWk3i_Ke5yBoycqWtNyf1zg@mail.gmail.com>
Date:	Sat, 18 Jun 2011 21:54:16 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Kay Sievers <kay.sievers@...y.org>, Greg KH <greg@...ah.com>,
	Nao Nishijima <nao.nishijima.xt@...achi.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	jcm@...hat.com, hare@...e.de, stefanr@...6.in-berlin.de,
	yrl.pp-manager.tt@...achi.com
Subject: Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure

On Fri, Jun 17, 2011 at 10:27, James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
> On Fri, 2011-06-17 at 01:04 +0200, Kay Sievers wrote:
>> >> We need many names, and we need all of them from the very beginning,
>> >> and they should not change during device lifetime unless the device
>> >> state changes.
>> >
>> > So that's actually an argument for leaving the links, surely?  We can
>> > have many inbound links, but the kernel can only print one name in
>> > messages, which would be the preferred name that was currently set.
>>
>> I really question any concept of _the_ name. My take on it: It will
>> never work in reality.
>
> OK, so lets take the common example: a desktop with three disks and an
> enclosure with three slots and labels "fred", "jim", and "betty".
>
> The desired outcome is that whenever the user manipulates those devices
> he uses a name related to the label, so whenever dmesg flags a problem,
> it says sd betty:  device offline or something.  Whenever he mounts, he
> mounts by /dev/disk/by-preferred/betty (or whatever the current udev
> vernacular is).  Whenever smartmon says there's an over temp problem. it
> says that fred has it;  cat /proc/partitions shows how fred, jim and
> betty are partitioned and so on.

Hm...

So there's already all this work going into an event-tracing framework,
and most of the interesting device errors are getting converted to use
functions such as "dev_err()" and the like.

Perhaps the kernel needs a "log" event?  You could add a basic unique-id
allocator (64-bit integer) and give each device or other interesting object a
unique "tag".  A generic printk without a "tag" field would automatically
get tag 0.

There would be another few special events generated to make it possible
to uniquely map tags to device-model objects (or filesystems or whatever)
long after the fact, including enough information to determine the parent
device or other key attributes.

Then all of the dev_dbg() would automatically generate the necessary
trace events tagged by device, with the log-level and "string" as the
payload.

Suddenly you can monitor a device (and optionally all of its parents or
children) for "interesting kernel events", even if that particular driver
is still doing all of its logging with "primitive" dev_err() printks.

Since it's tagged by device you can just install a modified "klogd" that
cooperates with udev to log events with information about exactly
which device-model node it applies to.  You can even have that
program generate dbus messages, so your desktop environment
can complain that the kernel has reported filesystem errors on that
thumbdrive you just plugged in, but that the media itself seems to
be fine (no I/O errors).

A future extension might be to allow trace-events to have a "fallback"
handler of sorts analogous to the way that audit messages are
currently handled.  If a process is monitoring events and has a filter
which matches the event then it will be handled by that process;
otherwise it will call the "fallback" handler and resort to a printk().

That would allow a more advanced driver to generate specific
status and error messages for consumption by monitoring software,
but still fall back to dmesg when the system is in single-user-mode
or the monitoring software dies, etc.

Thoughts?

Cheers,
Kyle Moffett
--
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/