[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140311151357.077c5a68@gandalf.local.home>
Date: Tue, 11 Mar 2014 15:13:57 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: "Frank Ch. Eigler" <fche@...hat.com>, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...nel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Johannes Berg <johannes.berg@...el.com>
Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not
set via debugfs
On Tue, 11 Mar 2014 17:34:23 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> > Who can load modules not as root?? That is utterly broken. As once you
> > can load a module, YOU ARE ROOT.
>
> udevd runs as root, and listens to events such as USB hotplug, and loads modules
> in the back of users. The users don't need to be root for this to happen.
udevd may run as a proxy for users. But it is still a root user.
Sysadmins are the ones that set up udevd. If you own your own box, you
are technically the sysadmin for it. Modifications to udev require sudo
privileges.
Tracepoints should not be something a non-sysadmin can modify or
enable. If you want non root users to do so, create a proxy daemon like
udevd to do it for them. But the kernel isn't going to allow that
directly.
>
> >
> > > fashion and is not suitable for the user-base we are targeting. I seems to
> > > be a user experience disaster IMHO.
> >
> > For your case only. But it is normal operation for normal uses of Linux.
>
> AFAIK pretty much all distros use udev nowadays. Are you suggesting that all
> users using udev and distribution kernels are not "normal uses of Linux" ?
udev is root, and is modified by root users. A normal user can not just
interact with udev. And sticking in a usb stick into a computer counts
as a sysadmin operation, even if the person doesn't official have the
title.
>
> >
> > >
> > > I'm OK as long as we have an elegant way forward. Ideally I would have
> > > prefered (1) to eliminate code duplication between tracers and tracepoint
> > > infrastructure (we have to reimplement a hash table similar to tracepoints
> > > within the tracer with solution (2)), but (2) technically works too.
> >
> > Here's what I propose then. We implement 2 for now. You can "duplicate"
> > the code into your own work.
>
> Works for me.
>
> > Then we should be able to simplify the
> > tracepoint code as it no longer will have the requirement to enable
> > tracepoints that do not exist.
>
> What happens for the case where we enable a tracepoint, and then the
> only module containing a callsite of that tracepoint is unloaded, and
> then reloaded ?
When a module is unloaded, it usually loses state. Is there any state
that is maintained for a module being unloaded and reloaded again?
Besides tracepoints? If not, then the module should lose its state for
tracepoints as well.
-- Steve
--
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