linux-kernel - Re: linux-next: build failure after merge of the driver-core tree

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] [day] [month] [year] [list]

Date:	Tue, 18 Mar 2014 11:58:57 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Greg KH <greg@...ah.com>, Stephen Rothwell <sfr@...b.auug.org.au>,
	Mark Brown <broonie@...nel.org>,
	Stewart Smith <stewart@...ux.vnet.ibm.com>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the driver-core tree

Hello, Ben.

On Tue, Mar 18, 2014 at 11:22:26AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
> > So, looked at the failed code.  The only necessary change seems to be
> > calling device_remove_file_self() in dump_ack_store() and then doing
> > kobject_put() directly afterwards, which would have been completely
> > fine as a merge fix patch.
> 
> Ok. Since there's no merge error, I'll have to tell Linus explicitly to
> apply it during the merge. I've never done that before but I suppose
> it's doable.

Yeah, that should be fine.  For the next tree, including the fix patch
in a temp branch and pulling that into your for-next branch should
work fine.

> Sorry I don't understand. Reverting the removal until after -rc1 (or
> later in the merge window) is the easiest path from my perspective and
> ensure no bisection breakage but whatever Linus prefers works here.

Merge fix doesn't cause any bisection issue either (because it *is* a
merge problem after all).  It could be just my personal preference but
I'd handle this one as merge fix.  If we rever the removal of the
interface, we'll probably need to mark it deprecated too as people
tend to fork off their devel branches before or at rc1.

> I don't think it's a drastic action or anything like that. It can
> trivially be re-applied once the merge window has settled. But I'm happy
> to also just send Linus a "apply this as a merge fixup" patch if he's
> happy with the method (as I said, I've never done that before on
> something that doesn't have an actual merge conflict to begin with)

Sure, either should work.

Thanks.

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