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]

Date:	Mon, 31 Aug 2015 14:25:25 -0600
From:	Jens Axboe <axboe@...com>
To:	Kent Overstreet <kent.overstreet@...il.com>
CC:	<torvalds@...ux-foundation.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] bcache revert

On 08/31/2015 02:17 PM, Kent Overstreet wrote:
>>> Really, as long as you think it's ok to commit patches without CCing the mailing
>>> list _or_ the maintainer, then fuck you. I wouldn't do that to you and I don't
>>> know anyone else who would, so as long as that's your attitude about it there's
>>> really nothing to discuss.
>>
>> I already said that, yes, it should have been posted. But it's not like it
>> was unreviewed. Or a massive change, by any stretch.
>
> And then you said you'd do it again.
>
> Look, it's about extending a basic courtesy - other people I work with have no
> issue with this. Tejun still pings me and lets me know about percpu refcount
> changes even though he's taken over as maintainer of that code since almost
> after I wrote it. Similarly with most anyone else I've worked with in the kernel
> community. I've always put quite a bit of effort into making sure I don't miss
> anyone on my CC lists when I was doing work in the block layer that touched all
> kinds of code.
>
> Why not you?

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.

>> And we're still not discussing the motives for why it looked like that in
>> the first place?
>
> Not terribly interested in doing that after the fact, when you've already
> bypassed me and gotten your patch in, and you're still saying you'd do it again.
> Sorry, I'm not having the discussion on those terms.

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.

-- 
Jens Axboe

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