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]

Message-ID: <20080830134304.GC17566@infradead.org>
Date:	Sat, 30 Aug 2008 09:43:04 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	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

On Wed, Aug 27, 2008 at 07:34:22PM +0400, Alexey Dobriyan wrote:
> On Tue, Aug 26, 2008 at 08:17:12PM -0400, Frank Ch. Eigler wrote:
> > Alexey Dobriyan <adobriyan@...il.com> writes:
> > 
> > > [...]  And some internal details still horrible and overdesigned
> > > just like at the very beginning.
> > 
> > Please point out specific areas, and I'm sure there will be a reasonable
> > explanation why they turned out this way.
> > 
> > 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.
> 
> God, you're in the very tricky Unix subsystem only a few people know
> intimately, and what we see? utrace code is just as tricky.
> 
> When you're confident that interaction with engines part is fine, all
> stupid bugs were fixed, go change struct utrace to pointer. Now it can
> very well be a lie to say less memory is used because slab allocator
> rounds up sizes to certain degree.

Yes.  And btw, the early utrace patches actually moved the ptrace
state into dynamically allocated per engine state, which would almost
cancel out the additional members required for utrace.  I'm not sure
why this went away in the meantime.

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