linux-kernel - Re: [RFC][PATCH 0/5] Signal scalability series

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: <20110930235625.GD2658@mtj.dyndns.org>
Date:	Fri, 30 Sep 2011 16:56:25 -0700
From:	Tejun Heo <htejun@...il.com>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	Tony Luck <tony.luck@...el.com>
Subject: Re: [RFC][PATCH 0/5] Signal scalability series

Hello,

On Fri, Sep 30, 2011 at 09:00:23PM +0100, Matt Fleming wrote:
> On Fri, 2011-09-30 at 18:52 +0200, Oleg Nesterov wrote:
> Well, sighand->siglock is seriously overused. It protects so much and I
> think it's pretty confusing. It took me long enough to figure out how
> many locks were really needed. But that's beside the point, having a
> single lock doesn't scale at all, and that's what this series is about.

But scalability for what?  What are the use cases here?  Do we care
enough about benefits to those use cases to accept the increased
complexity?  Having locks with broad coverage isn't necessarily evil.
If things are simpler that way and the protected paths aren't that
hot, who cares?  If splitting the locking makes things simpler, sure
but that doesn't look like the case here, so we need pretty strong
rationale to justify the added complexity.

Thank you.

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