linux-kernel - Re: [RFC PATCH 0/4] Persistent device name using alias name

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: <1310140451.3282.85.camel@mulgrave>
Date:	Fri, 08 Jul 2011 10:54:11 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Greg KH <greg@...ah.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	Nao Nishijima <nao.nishijima.xt@...achi.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	jcm@...hat.com, dle-develop@...ts.sourceforge.net,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	yrl.pp-manager.tt@...achi.com, dgilbert@...erlog.com,
	stefanr@...6.in-berlin.de, hare@...e.de
Subject: Re: [RFC PATCH 0/4] Persistent device name using alias name

On Fri, 2011-07-08 at 08:47 -0700, Greg KH wrote:
> On Fri, Jul 08, 2011 at 05:41:36PM +0200, Kay Sievers wrote:
> > On Fri, Jul 8, 2011 at 16:54, Greg KH <greg@...ah.com> wrote:
> > > On Fri, Jul 08, 2011 at 05:45:47PM +0900, Nao Nishijima wrote:
> > >> This patch series provides an "alias name" of the disk into kernel and procfs
> > >> messages. The user can assign a preferred name to an alias name of the device.
> > >>
> > >> Based on previous discussion (*), I changed patches as follows
> > >> - This is "alias name"
> > >> - An "alias name" is stored in gendisk struct
> > >> - Add document to Documentation/ABI/testing/sysfs-block
> > >> - When the user changes an "alias name", kernel notifies udev
> > >>
> > >> (*) http://marc.info/?l=linux-scsi&m=130812625531219&w=2
> > >
> > > I don't like it and I don't think it will really solve the root problem
> > > you are trying to address, but as the patches don't touch any code I
> > > maintain, there's not much I can do to object to it.
> > 
> > I can only repeat what I already wrote in detail earlier:
> > 
> > This approach seems to papers over the problem which emitting and
> > parsing free-text printk() messages with much-too-dumb tools cause. It
> > seems to fix the symptoms not the cause.
> > 
> > You can already write a udev rule today that logs _all_ symlinks of a
> > device at discovery time, and any later kernel message can safely be
> > associated with all possible names of the blockdev. No kernel changes
> > needed, all possible names are covered. That also works good enough
> > with our current stone-age tools for anybody who is able to scroll
> > back to the last log udev message in that same log file.
> > 
> > There can be by-definition no default udev rules assigning a proper
> > single name to a block device. There is never a valid single name for
> > a disks, so udev can not ship anything like that in the default setup,
> > so this stays as a custom hack.
> > 
> > We absolutely need _structured_ data for logging and error reporting,
> > not only to solve this problem. Along with the current free-text
> > printk(), we would be able to attach classifications, device
> > error/sense data, firmware register dumps and anything
> > interesting-for-debug to the messages.
> > 
> > We can't solve that problem in the kernel alone. Structured data from
> > the kernel will need to feed a smarter userspace logger that can index
> > and classify messages, merge current userspace data into it, and
> > provides hooks for the system management to act on critical failures
> > and raise notifications.
> > 
> > Structured logging seems like the solution for this and also to many
> > other problems in this area. Single custom names pushed into the
> > kernel might cover some rather exotic use cases, but I think, is not
> > what we are looking for.
> 
> I totally agree, but hey, no one listens to us :)

Yes, we did.  Everyone agrees structured logging would be the best long
term solution.  However, it's at least 10x the work presented here, plus
it would be a long process getting everyone to agree.  This looks like a
good 95% interim solution and it can be removed when structured logging
makes everything "just work(tm)".

I have also seen a couple of other attempts at structured logging which
both failed when the people proposing the patches realised how much work
it actually was, so I'm a bit sceptical we'll ever get there.  But hey,
you have the enthusiasm, propose it as a KS topic to get agreement that
we should do it and what the format should be and we can go from there.

James


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