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]

Date:	Tue, 24 Sep 2013 15:35:26 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Ingo Molnar <mingo@...nel.org>
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

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.

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