linux-kernel - Re: linux-next: build failure after merge of the final tree (sparc, ptrace trees related)

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, 14 Oct 2011 10:27:02 +0100
From:	Matt Fleming <matt.fleming@...el.com>
To:	David Miller <davem@...emloft.net>
Cc:	sfr@...b.auug.org.au, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org, tj@...nel.org, oleg@...hat.com,
	linux-arch <linux-arch@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the final tree
 (sparc, ptrace trees related)

On Fri, 2011-10-14 at 03:54 -0400, David Miller wrote:
> Ptrace folks can we not operate like this?  The only reason I found
> out about the set_current_blocked() transformations was by accident,
> because the original patch was posted to linux-kernel only so it never
> got queued up into sparc patchwork.
> 
> Then once Oleg mentioned it to me, it didn't even compile so I fixed
> it up and put the fixed up copy into my tree.  It also didn't
> transform the TS_RESTORE_SIGMASK cases in the sparc signal code, so I
> also added a patch to the sparc tree which took care of that.
> 
> Now you guys are creating conflicts against those fixed up patches in
> another non-sparc tree, and adding new kinds of build failures as
> well.
> 
> This doesn't work.

Sorry David, this is my fault.

The reason that these patches couldn't be taken through the arch trees
was because they were dependent on the non-arch patch that introduced
block_sigmask(). I figured it would make more sense to put all the
patches through Oleg's tree. It's now pretty clear I was wrong about
that.

In hindsight, what I should have done was got the first patch that
introduced block_sigmask() into 3.1, then waited till the next release
cycle and sent out all the arch patches to the arch maintainers. That
way the patches could have been pulled into the respective arch trees.

Guys, how did you want to sort this out? Should we get the first patch
into 3.1, then get all the arch maintainers to pick up their patches?

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