linux-kernel - Re: [PATCH 0/2] utrace

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:	Fri, 29 Aug 2008 15:04:41 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Roland McGrath <roland@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] utrace

Hi -


> > As for whether "struct utrace" should be a member of vs. pointed-to
> > from task_struct, it may come down to the perceived need to avoid
> > penalizing every thread with a hundred-odd bytes extra, whether or not
> > they are being utrace-controlled.
> 
> Yes, that's your price for avoiding more races, more code, more races,
> more tricky code and ultimately more ways to fsckup. [...]
> When you're confident that interaction with engines part is fine, all
> stupid bugs were fixed, go change struct utrace to pointer.  [...]

That's an idea worth considering, especially given the oopses you
found (thanks!).


> [...]
> > [...] All this code now exists in at
> > least prototype form, so if you need to see the bigger picture, look
> > that way.  Other users are anticipated, but first we need to get past
> > the chicken-and-egg.
> 
> There are no chickens and no eggs.
> 
> utrace is in RHEL4, RHEL5, FC6, FC7, FC8, FC9 kernels already.
> I can't believe RedHat allowed to totally rewrite ptrace based on some
> prototype code.

Well, that was how red hat broke the deadlock, and why RH kernels will
probably get working user-space systemtap probing earliest.


> > > This all similar to systemtap/markers story. Big changes under
> > > promises that now, now somebody will use our thing.
> > 
> > In what way do you think those promises are unfulfilled?  Systemtap
> > has interfaced to markers since the beginning,

> It just wants entry point, right?

(I don't understand what you mean.  If you mean "does systemtap just
want function entry points a la ftrace", then the answer is no, it
needs (& already has) more than that.)


> > and there are a bunch of markers in the tree.
> Total 3 in scheduler and in spufs (ppc-specific).

Some of those hits represent more via macros, but anyway, more on
their way (kmemcheck, lttng).


> Amazing improvement for ugly macros, more self-modified kernel,
> explicit reasons stated why they are stupid spelt in review and
> after entering tree, and general dislike of some maintainers to add
> more trace_mark() entries.

Regardless of the strength of technical objections/responses, there is
an ingrained cultural aspect to this that perhaps we'll break through
at the summit.

> So there were promises that markers will be useful, 10 months passed
> and they are still useless. [...]

They are already useful to their users.


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