linux-kernel - Re: [PATCH 28/31] Constify struct super

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: <b6fcc0a0912071030y4ca0deabk1635ec2f3e7ffe26@mail.gmail.com>
Date:	Mon, 7 Dec 2009 20:30:58 +0200
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Emese Revfy <re.emese@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 28/31] Constify struct super_operations for 2.6.32 v1

On 12/6/09, Emese Revfy <re.emese@...il.com> wrote:
> Alexey Dobriyan wrote:
>>> -   	struct inode *(*alloc_inode)(struct super_block *sb);
>>> +   	struct inode *(* const alloc_inode)(struct super_block *sb);
>>
>> Good rule is if adding const doesn't move object from one section
>> to another, it isn't worth it.
>>
>> I suggest we stick to it or risk another wave of jumbo patches.
>>
> If all instances of a given ops structure are const and we would like to
> preserve this policy for the future as well, then  it is very useful
> to give future programmers a strong hint about this policy by making
> the compiler complain about any violation attempts. Otherwise they may
> very well write code that modifies such structures and we will have to
> work extra to undo that (or change the policy but in that case it is
> good to know why we have to do that).

You may want to look what filesystems do with superblock operations.
And after super operations were made const writes to it will be caught
with readonly .rodata config option.

You're going too far with these modifiers.

Nothing will be caught.
--
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/