linux-kernel - Re: [PATCH] trivial

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: <alpine.LFD.0.999.0708310239340.31519@enigma.security.iitk.ac.in>
Date:	Fri, 31 Aug 2007 02:51:09 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
cc:	Alexey Dobriyan <adobriyan@...il.com>,
	Joe Perches <joe@...ches.com>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] trivial - constify sched.h

On Thu, 30 Aug 2007, Jan Engelhardt wrote:
> 
> On Aug 31 2007 02:11, Satyam Sharma wrote:
> >> So that you can actually pass in a const struct task_struct * without having
> >> to cast it back to [non-const].
> >
> >... which makes zero sense, because ...
> >
> >> Why one would have a const struct task_struct * in the first place
> >> is a different matter.
> >
> >... exactly.
> >
> >> But see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=77adbfbf4cf96fedf9b75bb330704828c187b190
> >
> >That commit const-ified struct timespec * or struct timeval * arguments,
> >which made sense because: (1) those functions really did not modify the
> >passed structs, and, (2) callers that pass in const struct timeval *
> >or const struct timespec * are indeed plausible (because one can plausibly
> >have const timeval/timespec structs). As the changelog suggested, those
> >callers
> >
> >were having to cast away the const qualifier before passing to
> >these functions to avoid seeing "passing argument discards qualifiers"
> >warnings. While (1) holds true for the sched.h case here, (2) does not
> >(and there are no warnings to shut up either).
> 
> "those callers". There was _exactly one_ caller, and that was an out-of-tree
> module. There were not any in-kernel callers before, and it did not generate
> any warning. That is perhaps why no one had constified it before me.

You've completely missed the point -- it is _plausible_ that callers
(even if just _one_) have const timespec/timeval structs, which is why
that commit made sense as I mentioned above (to shut up the warning that
would otherwise occur). This does not hold true for the sched.h / struct
task_struct case here -- I cannot imagine a const task_struct.

> This does
> not mean we should wait for a caller to pop up before constifying IMHO.

Going about const-ifying such function arguments as in here (for the sake
of type safety, where the function does not modify that argument), could
easily lead to *zillions* of patches such as this which would have
absolutely _zero_ impact on the actual kernel that gets built.

As I said, if someone really wants to do this, please go about constifying
_data_ instead -- that would make a (positive) difference.
-
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/