linux-kernel - Re: [GIT PULL] bcache revert

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: <20150831204231.GA17467@kmo-pixel>
Date:	Mon, 31 Aug 2015 12:42:31 -0800
From:	Kent Overstreet <kent.overstreet@...il.com>
To:	Jens Axboe <axboe@...com>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcache revert

On Mon, Aug 31, 2015 at 02:25:25PM -0600, Jens Axboe wrote:
> Kent, can we cut down on the victim playing? I said it should have been
> posted, did I not? And usually patches like that ARE always posted, but this
> beat the series of patches that it was a pre-patch for. Hence it just didn't
> get posted, and that was a mistake, after a private discussion where it
> ended up being cherry-picked for inclusion. Even for a trivial patch like
> this. But it's not the end of the world, it's not like I rewrote your
> architecture or grand caching design.

You're backpedalling and trying not to admit it. Look, would you do it again or
not? Because yes of course I'm going to call you out on it if you think this is
an acceptable thing to do, which is certainly what you started off saying.

> Grow up. We should revert a patch cleaning up macros with returns in them,
> but you won't really let us in on why?
> 
> Unless we can turn this into a REAL (and technical) discussion on why we
> should revert to the old code, I'm done spending time on this thread.

Because what's the point of having a technical discussion if you're checking in
code behind my back, and you refuse to say you won't do so again in the future?

And calling it "just a cleanup" is disingenuous. You're making a real semantic
change to the code, which never mind the pros and cons of the patch itself,
means I have now have to rebase ~1000 patches on top of it and it will _silently
break, in a nasty way_ any patches that make use of closures - you just made
a lot of work for me, especially if I want to keep my tree bisectable.

You remember how patches are supposed to go through the maintainer? This is part
of the reason. Are you starting to see why I'm in such a bad mood?
--
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/