Re: Fix UDF-FS potentially dereferencing null

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 04/17/04

  • Next message: Carl-Daniel Hailfinger: "Re: [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6" 
    Date:	Sat, 17 Apr 2004 10:14:54 -0700 (PDT)
To: Ingo Oeser <ioe-lkml@rameria.de>

    On Sat, 17 Apr 2004, Ingo Oeser wrote:
    >
    > Or even call the attribute "nonnull", because this is a very obvious
    > naming, even to non-native English readers.

    I did that at first, but decided that what I really wanted was "safe".

    "nonnull" is nice for avoiding the NULL check, but it's useless for
    anything else.

    "safe" to my mind means that not only is it not NULL, it's also safe to
    dereference early (ie "prefetchable"), which has a lot of meaning for the
    back-end.

    > "safe" can mean anything from "safe to use under spinlock" to
    > "you cannot get pregnant from using this variable".

    That's pretty much _exactly_ what "safe" means.

    Basically, a real C compiler is not allowed to dereference a pointer
    speculatively, since that could have undefined side effects in the
    machine. And "safe" means that there are no side effects, pregnancy-
    or otherwise.

    > GCC will not only optimize out the check, but also ensure that the we
    > will not pass NULL ptrs, if it can notice it. If this gets pushed high
    > enough (up to the register-like functions, where it gets first
    > assigned), we will never face this kind of problem anymore and document
    > this fact per function. Sounds like C coder heaven ;-)

    No. "nonnull" is useless. Even if it isn't NULL, the C standard does not
    allow the compiler to just dereference something willy-nilly.

    In contrast, "safe" means that the compiler could do something like

            int * safe ptr;

            if (!a)
                    a = *ptr;

    and know that it is "safe" to transform this into

            tmp = *ptr;
            a = a ? : tmp;

    which it otherwise can't necessarily determine.

                    Linus
                    
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Carl-Daniel Hailfinger: "Re: [RFC] [DRAFT] [udev PATCH] First attempt at vendor RAID support in 2.6"

    Relevant Pages

    • Re: [PATCH 1/3] Separate IRQ-stacks from 4K-stacks option
      ... You only have 4K safe to use in all current configurations. ... where the compiler is the offender). ... > overflowing the 4K interrupt stack? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] LZO de/compression support - take 3
      ... Lets just add the _unsafe postfix and leave "safe" alone, ... I don't like the symlink much either. ... I suspect it will probably damage performance unless the compiler is ...
      (Linux-Kernel)
    • Re: Qualifier "volatile" - probably OT.
      ... it's probably safe to assume that any C ... > compiler supports at least the entire C90 standard -- unless you have ... standard implementations, due to contractual obligations. ...
      (comp.lang.c)
    • Re: f() + g() * h()
      ... if it's a "safe" function that only ... How could the compiler prove that a function is safe to precompute at ... so external linkage might well not be an issue. ...
      (comp.lang.c)
    • Re: How to add/drop SCSI drives from within the driver?
      ... > userspace just to ensure you can never get it grown by the compiler ... but just to be safe). ... it forces the compiler to pessimise accesses to the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)