linux-kernel - Re: [PATCH 00/41] signal: Use set_current

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:	Wed, 17 Aug 2011 23:17:26 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/41] signal: Use set_current_blocked()

On Wed, 2011-08-17 at 19:01 +0200, Oleg Nesterov wrote:
> On 08/16, Matt Fleming wrote:
> >
> > Did you want me to send just the updated
> > versions of patches or the entire series again? It would seem over the
> > top to send the entire series.
> 
> This is up to you. Just in case, feel free to add my acked-by or
> reviewed-by to any patch I didn't comment explicitly. Or may be
> 
> > Also, are you going to pull these patches into your tree and send them
> > to Linus or would it be better to route them through -mm?
> 
> This is the question ;)
> 
> I simply do not know what should we do. I think this should be
> routed via maintainers.

Yeah, that seems like the best solution.

> Or I can push this into the poor ptrace branch... but I am
> thinking with horror about the possible conflicts in arch/ code...
> 
> What do you think?

I'll let all the maintainers take it through their trees.

> Damn. And I can't relax. This is very minor, but I still think
> it would be nice to have a common helper which plays sa_mask /
> SA_NODEFER to set ->blocked. But in this case, you probably need
> to resend the whole series ;)
> 
> I mean something like the patch below. OK, nevermind. Probably
> this factorization doesn't buy too much, but it will complicate
> the merging.

This does look like a decent clean up, especially because so many
architectures got this sequence wrong in the past. But yeah, it will
require me to rewrite half my series ;-)

Is it worth rewriting the series? Dunno. I'm not convinced that the
wrapper buys us enough for that, plus it'd increase the number of
patches.

Maybe it'd be better to do it as a separate set of patches?

-- 
Matt Fleming, Intel Open Source Technology Center

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