linux-kernel - Re: [PATCH 1/2] utrace core

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: <20080903121127.2B368154228@magilla.localdomain>
Date:	Wed,  3 Sep 2008 05:11:27 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] utrace core

> Again, embed struct utrace directly into task_struct. task_struct
> lifetime rules are way more tested than struct utrace ones.

The most consistent feedback I've seen to all new features is that they
mustn't add overhead when they're not being used.  So I never considered it
an option to bloat task_struct by ~120 bytes.  Of course much more than
that is entailed when a task is actually being traced somehow.  But the
presumption is that most tasks most of the time aren't, and that's what not
to bloat.

The revamp of the API after the first prototype made some of the internals
much simpler to implement, that had been very sticky in the old prototype
code.  But the allocation and freeing of struct utrace is an area I did not
fully revisit.  Buggy is buggy, and sure it needs to be tested and fixed.
I'm still inclined to look into making it right rather than punting.

> Add simple spinlock guarding all accesses (OK, I haven't looked very
> closely if it's possible)

I can't tell what you mean here.  Do you mean something different 
from struct utrace.lock?  If there were no pointer and its allocation
to synchronize, then what other lock would you be adding?

> INIT_RCU_HEAD is not needed, call_rcu() will overwrite rcu head unconditionally.

I see.  Thanks!  At some point, this was in the recommended example uses of
RCU.  This macro is still used in several places around the kernel.
Shouldn't they all be removed?  I wonder why it still exists in rcupdate.h.

Thanks,
Roland
--
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/