linux-kernel - Re: [pchecks v1 4/4] percpu: Add preemption checks to __this

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: <20130924172600.GD10261@gmail.com>
Date:	Tue, 24 Sep 2013 19:26:00 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Tejun Heo <tj@...nel.org>, akpm@...uxfoundation.org,
	Steven Rostedt <srostedt@...hat.com>,
	linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [pchecks v1 4/4] percpu: Add preemption checks to __this_cpu ops


* Christoph Lameter <cl@...ux.com> wrote:

> On Tue, 24 Sep 2013, Ingo Molnar wrote:
> 
> > > No he did not. He mentioned something about debug_smp_processor_id() at
> > > the end of a post after talking about something else. Given your
> > > comments now I see what was meant. That was not really obvious in the
> > > first place.
> >
> > Holy cow, this is what PeterZ wrote to you a week ago:
> >
> >      > +#ifdef CONFIG_PREEMPT
> >      > +extern void this_cpu_preempt_check(void);
> >      > +#else
> >      > +static inline void this_cpu_preempt_check(void) { }
> >      > +#endif
> >
> >      How about re-using debug_smp_processor_id() instead?
> >
> > Firstly, that sentence is as damn obvious as it gets.
> 
> No its not. This is a side comment and did not explain in detail what 
> was intended. There was another issue mentioned there. You did that in 
> your dysfunctional communication.

Sorry, if you cannot work it out from that very, clear plain sentence, or 
if you cannot at least ASK what it is about then you have absolutely ZERO 
business modifying core kernel code really...

> > Pointing out your repeated lack of cooperation in this matter is a 
> > statement of facts, not an 'insulting behavior'. Your wasting of other 
> > people's time is simply not acceptable.
> >
> > That I called you out on it might be embarrassing to you but there's a 
> > really easy solution to that: implement reviewer and maintainer 
> > requests and don't send sloppy patches repeatedly.
> 
> What is embarrasing here is your behavior. Usually I do not respond to 
> this kind of crap because its obvious that it is just that and it needs 
> to stand there for all to see not requiring a response.
> 
> And the patches were repeatedly send to you as well. You could have said 
> something earlier too when you realized that I did not note Peter's 
> comment.

I complained about it exactly when I noticed it. I usually don't assume 
that long-time contributors ignore very clear maintainer feedback, so I 
don't always notice such cases straight away.

> > > > Your lack of cooperation is getting ridiculous!
> > >
> > > And this kind of insulting behavior is really discouraging people to 
> > > do work on the kernel.

You can stop playing the victim card: you are not a newbie anymore by any 
definition, you've been hacking the Linux kernel for how long, 10+ years, 
writing hundreds of patches? People expect higher quality series from you 
and you need to learn to address criticism of your workflow as well.

You won't find a _single_ mail in the last 15+ years of lkml where I 
reacted strongly to a newbie being dense or abusive. Newbies can make all 
sorts of mistakes, it's part of the learning process - but after 10 years 
you are not a newbie anymore...

Thanks,

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