linux-kernel - Re: [PATCH] De-constify sched.h

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]

Message-ID: <20071026173246.GA7117@elte.hu>
Date:	Fri, 26 Oct 2007 19:32:46 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexey Dobriyan <adobriyan@...ru>
Cc:	torvalds@...l.org, linux-kernel@...r.kernel.org,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Joe Perches <joe@...ches.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] De-constify sched.h

* Alexey Dobriyan <adobriyan@...ru> wrote:

> Linus, please revert commit a8972ccf00b7184a743eb6cd9bc7f3443357910c aka
> "sched: constify sched.h" or apply the following patch instead.
> 
> [PATCH] De-constify sched.h

firstly, thank you for not Cc:-ing me. I learned about this revert only 
once it was done deal in Linus' tree. You objected to the patch 
originally when it was submitted to lkml, and plausible arguments were 
presented against your (bogus) objection:

   http://article.gmane.org/gmane.linux.kernel.janitors/14623

in that thread, two months ago, you essentially conceded Jan 
Engelhardt's argument by not replying to his points, so i kept Joe's 
patch. And now you continue this "discussion" by asking for a revert and 
not Cc:-ing me, Joe or Jan - which is quite sneaky.

> 1) Patch doesn't change any code here, so gcc is already smart enough
>    to "feel" constness in such simple functions.

the const markers indeed had no real purpose in terms of code generation 
(gcc can figure it out whether something is modified by an inline 
function), but they had a documentation/intent purpose, and they are 
plausible if a non-inlined function uses a const task struct in the 
future. For example any of these functions could be un-inlined and could 
use (internally) one of the remaining inlines - in that case code 
generation gets better from the constifying as well. There are also a 
good deal of helper functions around task struct which could be marked 
with const.

we do have other inline functions in include/linux/*.h with 'const' 
arguments, so marking arguments with const is not without precedent and 
this was pointed out to you in the original discussion.

> 2) There is no such thing as const task_struct. Anyone who think
>    otherwise deserves compiler warning.

-ENOPARSE. 'const struct task_struct *' says that the task struct is not 
supposed to be modified within that (inline) function. That _does_ make 
sense.

so unless i'm missing something, your request for revert was pretty 
rude, technically incorrect and you also tried to circumvent the normal 
course of discussion. I have no strong feelings either way technically 
(the patch is borderline - we dont actively pass around const 
task_struct pointers at the moment - but we could start doing so, if we 
had the constification), but i do have strong feelings against the kind 
of behavior you showed here.

	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/