sparse breakage triggered by rcu_read_lock() lockdep annotations - Kernel

This is a discussion on sparse breakage triggered by rcu_read_lock() lockdep annotations - Kernel ; FWIW, commit 851a67b825540a8e00c0be3ee25e4627ba8b133b aka "lockdep: annotate rcu_read_{,un}lock{,_bh}" causes sparse to trigger internal assertion in quite a few places over allyesconfig run. sparse: flow.c:805: rewrite_parent_branch: Assertion `changed' failed. Trimmed down testcase: void f(unsigned long ip); static void g(void) { if (1) ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: sparse breakage triggered by rcu_read_lock() lockdep annotations

  1. sparse breakage triggered by rcu_read_lock() lockdep annotations

    FWIW, commit 851a67b825540a8e00c0be3ee25e4627ba8b133b
    aka "lockdep: annotate rcu_read_{,un}lock{,_bh}"
    causes sparse to trigger internal assertion in quite a few places over
    allyesconfig run.

    sparse: flow.c:805: rewrite_parent_branch: Assertion `changed' failed.

    Trimmed down testcase:

    void f(unsigned long ip);
    static void g(void)
    {
    if (1) {
    f(({ __label__ x; x: (unsigned long)&&x; }));
    }
    f(({ __label__ x; x: (unsigned long)&&x; }));
    }

    #0 0x4001c410 in __kernel_vsyscall ()
    (gdb) bt
    #0 0x4001c410 in __kernel_vsyscall ()
    #1 0x40050701 in raise () from /lib/libc.so.6
    #2 0x40051e38 in abort () from /lib/libc.so.6
    #3 0x40049fcc in __assert_fail () from /lib/libc.so.6
    #4 0x08064947 in pack_basic_blocks (ep=0x411a1c6c) at flow.c:812
    #5 0x0805ffbf in linearize_symbol (sym=0x4103ec8c) at linearize.c:2154
    #6 0x080492a3 in main (argc=Cannot access memory at address 0x274d) at sparse.c:266

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

  2. Re: sparse breakage triggered by rcu_read_lock() lockdep annotations

    Alexey Dobriyan wrote:
    > FWIW, commit 851a67b825540a8e00c0be3ee25e4627ba8b133b
    > aka "lockdep: annotate rcu_read_{,un}lock{,_bh}"
    > causes sparse to trigger internal assertion in quite a few places over
    > allyesconfig run.
    >
    > sparse: flow.c:805: rewrite_parent_branch: Assertion `changed' failed.
    >
    > Trimmed down testcase:
    >
    > void f(unsigned long ip);
    > static void g(void)
    > {
    > if (1) {
    > f(({ __label__ x; x: (unsigned long)&&x; }));
    > }
    > f(({ __label__ x; x: (unsigned long)&&x; }));
    > }
    >
    > #0 0x4001c410 in __kernel_vsyscall ()
    > (gdb) bt
    > #0 0x4001c410 in __kernel_vsyscall ()
    > #1 0x40050701 in raise () from /lib/libc.so.6
    > #2 0x40051e38 in abort () from /lib/libc.so.6
    > #3 0x40049fcc in __assert_fail () from /lib/libc.so.6
    > #4 0x08064947 in pack_basic_blocks (ep=0x411a1c6c) at flow.c:812
    > #5 0x0805ffbf in linearize_symbol (sym=0x4103ec8c) at linearize.c:2154
    > #6 0x080492a3 in main (argc=Cannot access memory at address 0x274d) at sparse.c:266


    Thanks for the detailed report. Looking into it now.

    - Josh Triplett



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFHF5q7GJuZRtD+evsRAi+yAJwOuuybjXRRSIVtdhymlp K2YzTCaACfTeAv
    o3T4QqwbeCF614dLCYgJIig=
    =OlIi
    -----END PGP SIGNATURE-----


  3. Re: sparse breakage triggered by rcu_read_lock() lockdep annotations

    Err,

    Sparse does not support the local label syntax yet. It just treats the
    second label "x:" as the same as the first one. Then the linearize
    code gets serious confused when it saw one label get define in two
    places.

    The fix seems not trivial from the first look.

    Chris

    On 10/16/07, Alexey Dobriyan wrote:
    > FWIW, commit 851a67b825540a8e00c0be3ee25e4627ba8b133b
    > aka "lockdep: annotate rcu_read_{,un}lock{,_bh}"
    > causes sparse to trigger internal assertion in quite a few places over
    > allyesconfig run.
    >
    > sparse: flow.c:805: rewrite_parent_branch: Assertion `changed' failed.
    >
    > Trimmed down testcase:
    >
    > void f(unsigned long ip);
    > static void g(void)
    > {
    > if (1) {
    > f(({ __label__ x; x: (unsigned long)&&x; }));
    > }
    > f(({ __label__ x; x: (unsigned long)&&x; }));
    > }
    >
    > #0 0x4001c410 in __kernel_vsyscall ()
    > (gdb) bt
    > #0 0x4001c410 in __kernel_vsyscall ()
    > #1 0x40050701 in raise () from /lib/libc.so.6
    > #2 0x40051e38 in abort () from /lib/libc.so.6
    > #3 0x40049fcc in __assert_fail () from /lib/libc.so.6
    > #4 0x08064947 in pack_basic_blocks (ep=0x411a1c6c) at flow.c:812
    > #5 0x0805ffbf in linearize_symbol (sym=0x4103ec8c) at linearize.c:2154
    > #6 0x080492a3 in main (argc=Cannot access memory at address 0x274d) at sparse.c:266
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    >

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

  4. Re: [PATCH] Re: sparse breakage triggered by rcu_read_lock() lockdep annotations

    Christopher Li wrote:
    > OK, I get a trivial fix after all. The test case is fixed now.
    > I haven't done much test otherwise.
    >
    > See the patch attached.


    Nice work Chris! Patch applied and pushed out.

    I may roll an 0.4.1 release in the near future to fix kernel
    builds with Sparse.

    - Josh Triplett



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFHGsisGJuZRtD+evsRAvRoAJ4pMW/OVO7I2SoWCSIlW11pNx5FqACgjG3m
    FdZN8gvX5eRftrcuMsjnTgk=
    =a/D+
    -----END PGP SIGNATURE-----


+ Reply to Thread