linux-kernel - Re: [PATCH 00/16] mm: prepare for converting vm->vm

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:	Thu, 22 Mar 2012 15:39:00 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Konstantin Khlebnikov <khlebnikov@...nvz.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Minchan Kim <minchan@...nel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hughd@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>
Subject: Re: [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit

On Thu, Mar 22, 2012 at 3:24 PM, Konstantin Khlebnikov
<khlebnikov@...nvz.org> wrote:
>
> # define __nocast       __attribute__((nocast))
>
> typedef long __nocast long_t;

So the intention is that this really creates a *new* type.

So "long_t" really is a different type from "long", but because
__nocast is so weak, it happily casts to another integer type of the
same size.

But a pointer to it is different, the same way "int *" is different
from "long *" even if "int" and "long" happen to have the same size.
So I do think that the warning you quote is correct and expected:

> 1.c:13:12: warning: incorrect type in argument 1 (different modifiers)
> 1.c:13:12:    expected int [nocast] [usertype] *x
> 1.c:13:12:    got int *<noident>
> 1.c:13:12: warning: implicit cast to nocast type
>
> Is this ok?

Yes.

The thing about __nocast is that it's so *very* very easy to lose it.
For example, do this:

  typedef long __nocast long_t;

  int main(long_t a)
  {
        return a;
  }

and you get the (expected) warning.

HOWEVER. Now do "return a+1" instead, and the warning goes away. Why?
Because the expression ends up having just the type "long", because
the "a" mixed happily with the "1" (that was cast from 'int' to 'long'
by the normal C type rules).

That is arguably a bug, but this kind of thing really wasn't what
__nocast was designed for. The __nocast design ended up being too
weak, though, and we hardly use it in the kernel.

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