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: <CAPXgP13eh9ibYBq4vFo21TrQiu5gvaZtOX4J3AscPHZix6BVSg@mail.gmail.com>
Date:	Thu, 22 Dec 2011 04:44:08 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Tim Bird <tim.bird@...sony.com>
Cc:	Greg KH <gregkh@...e.de>,
	linux-embedded <linux-embedded@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	john stultz <johnstul@...ibm.com>,
	Brian Swetland <swetland@...gle.com>,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: RFC: android logger feedback request

On Thu, Dec 22, 2011 at 03:12, Tim Bird <tim.bird@...sony.com> wrote:
> On 12/21/2011 05:47 PM, Greg KH wrote:

>> Again, please see what we are already doing in the kernel and userspace,
>> I think a lot of the above is already implemented.
>
> I don't know what systemd has got going on in user-space.  I'm looking
> at a very recent kernel, and I see no support for multiple log channels,
> or an optimized open/write path.

> How does current systemd prevent user-space messages from crowding
> out kernel messages?  (or vice-versa).

It intentionally doesn't. Splitting messages in separate stores is not
what we want in the general use case.

Syslog has the 'facility' for that, and it works just good enough. We
think that filtering in the receiver is more flexible and useful, than
to have multiple stores of pretty much the same type.

If you have multiple stores, you always have to fight the ordering
problem, and that really creates problems sometimes.

We are very convinced, that there should be a single entry only for
logging, and not multiple, and the filtering should happen on the
receiver side.

> Since you've been doing
> a lot of work on logging, do you have any existing metrics for logging
> overhead via the kernel log buffer?

Which overhead? I don't really think that is too interesting. Writing
to a device node or socket and copy it to the kernel's ring buffer,
not sure if it has an interesting potential of being optimized, if you
don't use fancy consoles and such.

We have no numbers, but until I see numbers of a real world problem, I
would expect there is no actual problem.

>> Which brings me back to my original question, what does this code do,
>> that is not already present in the kernel, and why is a totally new
>> interface being proposed for it?
>
> At the least, it supports multiple log channels.  Quite frankly my mind
> has been blown a bit by the suggestion to overload the kernel log buffer
> with user-space messages.  I would never have gone that route. But I'll have
> to find out more about this systemd thing to answer your question.

It's just fine. And honestly, for early boot and debugging
interleaving is exactly what you want, because userspace is triggering
the actions in the kernel, and you want to see that in the same
channel.

Also you can use netconsole and all the weird stuff people support for
the kernel and get the messages from early boot userspace including
intramfs there.

> Secondly, this is not a particularly new or radical interface. It is new
> to legacy Linux, but it's been in the Android Linux kernel for some years
> now, and it has worked well.

Sure, it's understandable, it sounds like something that made sense
when it was invented, and which probably still make a lot of sense for
Android today. But I don't think it should be discussed as a general
purpose Linux use case, or something that replaces kmsg. It does not
look like too interesting for general needs today outside of Android.

We probably just want the simple stuff we have today, or something
that really solves the structured logging problem in a proper way.
Something slightly better, with almost the same model and limitations,
than what we have already, is probably not that important enough to
make changes.

Thanks,
Kay
--
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