linux-kernel - Re: [PATCH 0/1] Constify struct address_space

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: <4B295E12.1000408@gmail.com>
Date:	Wed, 16 Dec 2009 23:24:18 +0100
From:	Emese Revfy <re.emese@...il.com>
To:	Pavel Machek <pavel@....cz>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Matthew Wilcox <matthew@....cx>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 0/1] Constify struct address_space_operations for 2.6.32-git-053fe57ac
 v2

Pavel Machek wrote:
> Hi!
> 
>>> One const in structure declaration seems to be just enough, see:
>>>
>>> const struct a {
>>> 	void (* f)(void);
>>> 	void (* const g)(void);
>>> } s;
>>>
>>> void h(void)
>>> {
>>> 	struct a *p = &s;
>>> 	s.f = 0;
>>> 	s.g = 0;
>>> 	p->f = 0;
>>> 	p->g = 0;
>>> }
>>>
>>>
>>> delme.c: In function 'h':
>>> delme.c:8: warning: initialization discards qualifiers from pointer target type
>>> delme.c:9: error: assignment of read-only variable 's'
>>> delme.c:10: error: assignment of read-only variable 's'
>>> delme.c:12: error: assignment of read-only member 'g'
>>>
>>> You get clean-enough warnings.
>> Notice how you got an error for line 12 (p->g assignment) but no warning or error
>> at all for line 11 (p->f assignment). This example illustrates what I was explaining
>> so far:
> 
> And notice how you get warning for line 8? That's what I'm talking
> about, and it should be enough to make the developer think about what
> he's doing. 
> 									Pavel

You are talking about in-kernel ops structures whose constness will
prevent bad code from being written. On the other hand, I was talking
about new code yet-to-enter the kernel where the developer has no indication
that he should be using a const ops structure (other than perhaps checkpatch
except apparently things easily fall through the cracks, see my series for
file_operations) and this is where const structure fields would help.

In any case, as I indicated already, I will remove these parts from the patches.
--
Emese
--
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/