Did you update the addresses of the kernel functions?

    #define COMMIT_CREDS_ADDR (0xffffffff81094250)
    #define PREPARE_KERNEL_CREDS_ADDR (0xffffffff81094550)

even if you don't update the addresses you would at least get an oops if the exploit is working. I've explained the problem with rcu calls in my post https://cyseclabs.com/page?n=02012016 reply but did not describe the technique for ordering these calls. The way they do things in the poc, you'd be lucky if it succeeds once out of 100.

If you have SMAP, i.e. an Haswell or newer Intel CPU, you should not be vulnerable, so that could be an explanation.

Is SMAP required for mitigation, or is SMEP enough?

IIUC SMEP is on Sandy Bridge processors too.

SMEP would stop this particular exploit because it returns into usermode but SMEP is trivial to bypass on linux if there is no KASLR or other mitigation (apparently there are compiler plugins that remove popular stack pivot gadgets).

According the lwn comments it should be sufficient (and the post by perception-point suggests that it would at least make things more difficult), but I haven't the hardware to test for myself.

I have Sandy Bridge, i7-2820QM. The exploit code has been running for nearly an hour, still "Increfing..."

EDIT:

    [chris@f23m cve20160728]$ ./cve_2016_0728 PP_KEY
    uid=1000, euid=1000
    Increfing...
    finished increfing
    forking...
    finished forking
    caling revoke...
    uid=1000, euid=1000
    sh-4.3$